Acquisition des connaissances : comment recueillir et formaliser une expertise ?

L’acquisition des connaissances désigne l’ensemble des méthodes utilisées pour identifier, recueillir, analyser et formaliser les connaissances utiles à un système.

Ces connaissances peuvent se trouver dans :

l’expérience de spécialistes ;
des procédures ;
des rapports ;
des bases de données ;
des réglementations ;
des échanges professionnels ;
des pratiques de terrain ;
des systèmes informatiques existants.

L’objectif n’est pas seulement de collecter de l’information. Il faut comprendre ce que les personnes savent réellement, comment elles prennent leurs décisions, quelles règles elles appliquent et dans quelles situations elles adaptent leur comportement.

L’acquisition constitue donc une étape centrale du Knowledge Engineering.

Avant de représenter une connaissance dans une ontologie, un graphe ou une base de règles, il faut d’abord parvenir à la faire apparaître.

Ce que vous allez comprendre

À la fin de cet article, vous saurez :

définir l’acquisition des connaissances ;
identifier les principales sources de connaissances ;
distinguer collecte d’informations et acquisition de connaissances ;
utiliser différentes méthodes d’entretien et d’observation ;
repérer les règles, les relations et les exceptions ;
comprendre le rôle de la validation par les experts ;
organiser un processus complet d’acquisition.

Qu’est-ce que l’acquisition des connaissances ?

L’acquisition des connaissances est le processus par lequel une expertise humaine, documentaire ou organisationnelle est transformée en éléments suffisamment explicites pour être représentés dans un système.

Le processus peut être résumé ainsi :

Sources de connaissances
          ↓
Collecte
          ↓
Analyse
          ↓
Explicitation
          ↓
Formalisation
          ↓
Validation
          ↓
Intégration dans un système

L’acquisition peut conduire à identifier :

des concepts ;
des catégories ;
des relations ;
des règles ;
des procédures ;
des exceptions ;
des critères de décision ;
des contraintes ;
des niveaux de confiance ;
des sources de référence.

Ces éléments pourront ensuite être organisés grâce aux méthodes de représentation des connaissances.

Collecter des informations ne suffit pas

Une organisation peut posséder une grande quantité de documents sans disposer d’une connaissance structurée.

Par exemple, un dossier peut contenir :

cinquante procédures ;
plusieurs années de rapports ;
des centaines de courriels ;
des tableaux de suivi ;
des comptes rendus d’incidents.

Cette documentation constitue une source importante, mais elle ne permet pas toujours de comprendre immédiatement :

quels concepts sont essentiels ;
quelles règles sont réellement appliquées ;
quelles procédures sont encore valides ;
quelles exceptions existent ;
quelles informations sont contradictoires ;
quelles connaissances restent uniquement dans l’expérience des professionnels.

L’acquisition des connaissances cherche donc à passer d’un ensemble de contenus à une représentation organisée du savoir.

Les principales sources de connaissances

Les connaissances utiles à un projet peuvent provenir de plusieurs types de sources.

Les experts du domaine

Les experts sont les personnes qui possèdent une expérience approfondie du sujet traité.

Il peut s’agir :

de techniciens ;
de juristes ;
de médecins ;
de commerciaux ;
de responsables qualité ;
de formateurs ;
de chercheurs ;
d’opérateurs ;
de gestionnaires ;
de conseillers.

Ils connaissent souvent :

les règles officielles ;
les pratiques réelles ;
les erreurs fréquentes ;
les cas particuliers ;
les critères de décision ;
les risques ;
les raccourcis efficaces.

Une partie de cette expertise est explicite. Une autre relève de la connaissance tacite.

Les documents

Les documents peuvent contenir des connaissances déjà formulées.

Exemples :

manuels ;
procédures ;
normes ;
contrats ;
rapports ;
guides ;
fiches techniques ;
comptes rendus ;
articles ;
documentation interne.

Ils permettent d’identifier un premier vocabulaire et les règles officielles du domaine.

Cependant, ils doivent être analysés avec prudence.

Un document peut être :

ancien ;
incomplet ;
redondant ;
contradictoire ;
trop général ;
dépassé par la pratique ;
applicable uniquement à certains cas.

Les bases de données

Les bases de données contiennent des faits et des observations accumulés.

Exemples :

incidents ;
interventions ;
commandes ;
dossiers clients ;
diagnostics ;
décisions ;
évaluations ;
historiques de maintenance.

Ces données peuvent révéler :

des régularités ;
des relations ;
des fréquences ;
des exceptions ;
des séquences d’événements ;
des facteurs associés à une décision.

Elles ne remplacent toutefois pas l’analyse métier. Une corrélation observée dans les données ne constitue pas automatiquement une règle valide.

Les pratiques de terrain

L’observation du travail réel permet de découvrir ce que les personnes font effectivement.

Elle peut révéler :

des étapes absentes des procédures ;
des vérifications informelles ;
des adaptations ;
des raccourcis ;
des habitudes ;
des critères perceptifs ;
des échanges avec d’autres personnes.

Cette source est particulièrement importante lorsque la pratique diffère de la documentation officielle.

Les systèmes existants

Un ancien logiciel, un tableur ou un moteur de règles peut déjà contenir une partie de la connaissance métier.

Il faut alors analyser :

les champs utilisés ;
les catégories ;
les règles programmées ;
les messages d’erreur ;
les statuts ;
les dépendances ;
les exceptions ;
les conditions cachées dans le code.

Le système existant peut constituer une source précieuse, mais il ne doit pas être considéré comme nécessairement correct ou complet.

Les utilisateurs

Les utilisateurs finaux possèdent une connaissance particulière : celle des besoins, des difficultés et des usages réels.

Ils peuvent expliquer :

quelles questions reviennent souvent ;
quelles informations sont difficiles à trouver ;
quelles réponses sont jugées utiles ;
quelles erreurs sont problématiques ;
quels niveaux de détail sont nécessaires.

L’acquisition doit donc inclure les experts du domaine, mais également les personnes qui utiliseront le futur système.

Les étapes de l’acquisition des connaissances

Un processus efficace peut être organisé en plusieurs étapes.

1. Définir le problème à résoudre

Avant de commencer les entretiens ou l’analyse documentaire, il faut préciser l’objectif.

Le système devra-t-il :

diagnostiquer une panne ;
recommander une formation ;
vérifier une conformité ;
répondre à des questions ;
orienter un client ;
retrouver des documents ;
expliquer une décision ;
détecter un risque ?

Une acquisition sans objectif devient rapidement trop large.

Il est impossible de recueillir toute la connaissance d’un domaine. Il faut sélectionner ce qui est utile au problème traité.

2. Définir les questions auxquelles le système devra répondre

Les questions servent à délimiter le contenu du futur système.

Exemples :

Quelles causes peuvent expliquer ce symptôme ?
Quel document s’applique à cette situation ?
Quel participant possède les prérequis nécessaires ?
Quelle règle justifie cette décision ?
Quels composants sont compatibles ?
Quelle procédure doit être suivie ?
Quelles personnes possèdent cette compétence ?

Ces questions orientent directement l’acquisition.

Elles permettent de savoir quelles connaissances doivent être identifiées et représentées.

3. Identifier les sources pertinentes

Il faut ensuite dresser une carte des sources disponibles.

Source	Contenu possible	Risque principal
Expert	Expérience et raisonnement	Connaissance difficile à verbaliser
Document	Règles et procédures	Contenu ancien ou incomplet
Base de données	Historique des cas	Données sans explication
Observation	Pratique réelle	Temps d’analyse important
Logiciel existant	Règles déjà implémentées	Logique obscure ou dépassée
Utilisateur	Besoins et difficultés	Vision partielle du domaine

Toutes les sources ne possèdent pas la même fiabilité.

Il faut donc comparer les informations et documenter leur provenance.

4. Construire un premier vocabulaire

Avant d’aller trop loin, il est utile de recenser les termes employés dans le domaine.

Exemple dans la formation :

formation ;
session ;
compétence ;
prérequis ;
niveau ;
certification ;
participant ;
formateur ;
évaluation.

Il faut ensuite vérifier :

si deux mots désignent la même chose ;
si un mot possède plusieurs significations ;
si plusieurs équipes utilisent des vocabulaires différents ;
si certains termes sont trop vagues ;
si des acronymes doivent être définis.

Ce premier vocabulaire servira de base à la future ontologie informatique.

5. Recueillir des cas concrets

Les cas concrets sont souvent plus utiles que les explications générales.

Au lieu de demander :

Comment traitez-vous un incident ?

Il est préférable de demander :

Pouvez-vous décrire le dernier incident difficile que vous avez traité ?

Le cas concret permet d’identifier :

le contexte ;
les informations disponibles ;
les hypothèses formulées ;
les décisions prises ;
les critères utilisés ;
les alternatives rejetées ;
les résultats obtenus.

Les experts expliquent généralement mieux leur raisonnement lorsqu’ils s’appuient sur une situation réelle.

6. Identifier les concepts et les relations

À partir des entretiens et des documents, il faut repérer les objets importants.

Exemple dans un service de support :

Concepts

client ;
incident ;
produit ;
symptôme ;
cause ;
procédure ;
solution ;
niveau de priorité.

Relations

Un incident concerne un produit.

Un incident présente un symptôme.

Un symptôme peut indiquer une cause.

Une procédure traite une cause.

Une solution résout un incident.

Ces relations pourront ensuite être représentées dans un graphe de connaissances.

7. Identifier les règles

Une règle relie des conditions à une conclusion ou à une action.

Exemple :

SI le client ne peut plus utiliser le service
ET si aucune solution de contournement n’existe
ALORS l’incident est critique.

Autre exemple :

SI la formation exige le niveau intermédiaire
ET si le participant possède seulement le niveau débutant
ALORS l’inscription doit être refusée ou validée manuellement.

Pour identifier une règle, il faut demander :

Dans quelles conditions prenez-vous cette décision ?
Quels éléments sont indispensables ?
Qu’est-ce qui pourrait modifier votre décision ?
Existe-t-il des exceptions ?
Cette règle est-elle toujours vraie ?
Quel niveau de confiance lui accordez-vous ?

8. Identifier les exceptions

Les exceptions sont souvent aussi importantes que les règles.

Une règle générale peut sembler correcte :

SI une facture est échue
ALORS envoyer une relance.

Mais les experts peuvent préciser :

Ne pas relancer si un litige est ouvert.

Ne pas relancer si un accord de paiement est en cours.

Appliquer une procédure spéciale pour les comptes stratégiques.

Sans ces exceptions, le système produirait des décisions incorrectes.

9. Formaliser les connaissances

La formalisation transforme le contenu recueilli en éléments structurés.

Une déclaration d’expert comme :

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

peut être décomposée ainsi.

Concepts

machine ;
température ;
changement de série ;
réglage ;
panne mécanique.

Condition

La température augmente après un changement de série.

Règle

SI la machine chauffe après un changement de série
ALORS vérifier le réglage avant d’examiner une panne mécanique.

Ordre de diagnostic

Réglage
  ↓ avant
Panne mécanique

Cette connaissance pourra ensuite être intégrée dans un système expert.

10. Valider avec les experts

Une connaissance formalisée doit être vérifiée.

La validation consiste à demander :

Cette définition est-elle correcte ?
Cette règle correspond-elle à la pratique ?
Les conditions sont-elles complètes ?
Existe-t-il des exceptions ?
Le vocabulaire est-il compris par tous ?
Cette règle est-elle encore actuelle ?
Le système devrait-il toujours appliquer cette conclusion ?

La validation peut être réalisée à partir :

d’entretiens de relecture ;
d’ateliers collectifs ;
de scénarios ;
de cas historiques ;
de tests ;
de comparaisons entre experts.

Les principales méthodes d’acquisition

Plusieurs méthodes peuvent être combinées dans un même projet.

L’entretien libre

L’expert explique son activité avec peu de contraintes.

Cette méthode est utile pour :

découvrir le domaine ;
identifier le vocabulaire ;
comprendre les grandes étapes ;
repérer les sujets importants.

Elle possède toutefois une limite : l’expert peut rester général ou oublier des éléments devenus automatiques.

L’entretien semi-directif

L’entretien suit une grille de questions, tout en laissant l’expert développer ses réponses.

Exemples de questions :

Quels sont les principaux objets du domaine ?
Quels problèmes rencontrez-vous ?
Quelles informations utilisez-vous ?
Comment prenez-vous cette décision ?
Quels cas sont difficiles ?
Quelles erreurs sont fréquentes ?
Quelles exceptions connaissez-vous ?

Cette méthode offre un bon équilibre entre structure et exploration.

L’entretien structuré

Les mêmes questions sont posées à plusieurs experts.

Il permet de comparer :

les définitions ;
les procédures ;
les règles ;
les divergences ;
les niveaux d’expérience.

Cette méthode est utile lorsque plusieurs personnes interviennent sur le même processus.

L’observation directe

L’ingénieur des connaissances observe l’expert pendant son activité.

Il note :

les actions ;
les documents consultés ;
les informations vérifiées ;
les interruptions ;
les décisions ;
les outils utilisés ;
les échanges avec d’autres personnes.

L’observation fait apparaître des connaissances qui ne sont pas toujours exprimées en entretien.

La verbalisation simultanée

L’expert décrit ce qu’il pense pendant qu’il réalise une tâche.

Exemple :

Je vérifie d’abord cette valeur, car si elle est normale, je peux écarter deux causes fréquentes.

Cette méthode permet de recueillir une partie du raisonnement au moment où il se déroule.

Elle peut toutefois perturber certaines activités complexes ou très rapides.

L’analyse rétrospective

Après une intervention, l’expert reconstruit son raisonnement.

Questions possibles :

Qu’avez-vous observé en premier ?
Quelle hypothèse avez-vous formulée ?
Quelle information a confirmé cette hypothèse ?
Quelles autres causes avez-vous écartées ?
Qu’est-ce qui aurait pu modifier votre décision ?

Cette méthode est particulièrement utile pour analyser les décisions complexes.

L’analyse documentaire

Les documents sont étudiés pour identifier :

les termes ;
les concepts ;
les règles ;
les responsabilités ;
les procédures ;
les contraintes ;
les références ;
les dates de validité.

L’analyse documentaire doit également repérer :

les contradictions ;
les doublons ;
les versions ;
les passages ambigus ;
les différences de vocabulaire.

Les questionnaires

Les questionnaires permettent de recueillir des réponses auprès d’un grand nombre de personnes.

Ils sont utiles pour :

comparer des pratiques ;
identifier des fréquences ;
repérer des désaccords ;
évaluer la compréhension d’un vocabulaire.

Ils sont moins adaptés à l’exploration fine des connaissances tacites.

Les ateliers collectifs

Plusieurs experts construisent ou corrigent ensemble une représentation du domaine.

Ils peuvent travailler sur :

une carte conceptuelle ;
une taxonomie ;
une liste de règles ;
un processus ;
un graphe ;
des scénarios.

L’atelier permet de faire apparaître rapidement les accords et les divergences.

Les cartes conceptuelles

Une carte conceptuelle représente les concepts et leurs relations.

Exemple :

Incident
├── concerne → Produit
├── possède → Niveau de priorité
├── présente → Symptôme
├── peut avoir pour cause → Défaillance
└── est résolu par → Solution

L’expert peut facilement corriger ou compléter cette représentation.

La carte constitue souvent une étape intermédiaire avant la construction d’une ontologie.

Le tri de cartes

Des termes ou concepts sont inscrits sur des cartes.

L’expert doit :

les regrouper ;
les classer ;
expliquer ses choix ;
nommer les catégories ;
identifier les concepts proches.

Cette méthode aide à construire une taxonomie et à comprendre la structure mentale du domaine.

L’analyse de scénarios

L’expert est confronté à une situation réelle ou fictive.

On lui demande :

ce qu’il ferait ;
quelles informations il rechercherait ;
quelles règles il appliquerait ;
quelles erreurs il éviterait ;
ce qui modifierait sa décision.

Les scénarios sont particulièrement utiles pour identifier les règles conditionnelles.

Comment interroger efficacement un expert ?

La qualité des questions influence directement la qualité des connaissances recueillies.

Éviter les questions trop générales

Question trop large :

Comment faites-vous votre travail ?

Question plus précise :

Quelles informations vérifiez-vous avant de décider qu’un incident est critique ?

Demander des exemples

Question :

Pouvez-vous décrire un cas où la procédure habituelle n’a pas fonctionné ?

Les exemples font apparaître les exceptions.

Comparer deux cas

Question :

Quelle différence existe-t-il entre un incident urgent et un incident critique ?

La comparaison oblige l’expert à expliciter les critères de distinction.

Demander les conditions

Question :

Dans quelles situations cette règle ne s’applique-t-elle pas ?

Cette formulation aide à détecter les limites.

Demander les signaux

Question :

Quel indice vous fait penser que la cause vient du réseau plutôt que du matériel ?

Elle fait apparaître les éléments utilisés dans le diagnostic.

Demander le niveau de confiance

Question :

Cette conclusion est-elle certaine ou seulement probable ?

Toutes les connaissances ne possèdent pas le même degré de certitude.

Demander la source

Question :

Cette règle vient-elle d’une procédure, d’une réglementation ou de votre expérience ?

La provenance doit être conservée dans la future base de connaissances.

Les difficultés fréquentes

L’expert omet les évidences

Une personne expérimentée peut oublier de mentionner une étape devenue automatique.

Il faut donc demander :

Que ferait un débutant ?
Quelle erreur ferait-il probablement ?
Quelle information vous semble évidente mais ne le serait pas pour lui ?

L’expert reconstruit son raisonnement

Une justification donnée après coup ne correspond pas toujours exactement à la décision réelle.

Il est utile de croiser :

entretien ;
observation ;
analyse de cas ;
données historiques.

Les experts ne sont pas d’accord

Les divergences peuvent venir :

de pratiques différentes ;
de contextes différents ;
de niveaux d’expérience ;
de règles locales ;
d’une véritable incertitude.

Le désaccord doit être documenté plutôt que masqué.

Le vocabulaire est ambigu

Un même mot peut désigner plusieurs concepts.

Exemple :

une « formation » comme programme ;
une « formation » comme session ;
une « formation » comme action financée.

Chaque sens doit être distingué.

Les documents se contredisent

Il faut alors identifier :

la version la plus récente ;
l’autorité de la source ;
le champ d’application ;
les changements intervenus ;
la règle réellement appliquée.

Les règles évoluent

Une connaissance n’est pas nécessairement stable.

Elle peut changer en fonction :

d’une réglementation ;
d’un produit ;
d’un processus ;
d’une organisation ;
d’un retour d’expérience.

Le système doit donc prévoir la maintenance et la date de validité.

Comment documenter une connaissance acquise ?

Chaque connaissance importante devrait être accompagnée de métadonnées.

Exemple :

Connaissance :
Un incident bloquant sans solution de contournement est critique.

Type :
Règle métier.

Source :
Responsable du support.

Date de validation :
12 juillet 2026.

Périmètre :
Clients professionnels.

Exception :
Ne s’applique pas aux environnements de test.

Niveau de confiance :
Élevé.

Ces informations facilitent :

la validation ;
la traçabilité ;
la mise à jour ;
l’explication ;
la gouvernance.

Exemple complet : support technique

Une entreprise souhaite créer un assistant capable d’aider les techniciens à diagnostiquer des incidents.

Étape 1 — Questions attendues

Le système devra répondre à des questions comme :

Quelle cause peut expliquer ce symptôme ?
Quelle vérification faut-il effectuer en premier ?
Quelle procédure correspond à ce produit ?
Quand faut-il transmettre le dossier à un spécialiste ?

Étape 2 — Sources

procédures techniques ;
historique des incidents ;
entretiens avec les techniciens ;
documentation des produits ;
observations des interventions.

Étape 3 — Concepts

produit ;
composant ;
symptôme ;
cause ;
test ;
procédure ;
solution ;
incident.

Étape 4 — Relations

Un produit contient un composant.

Un incident présente un symptôme.

Un symptôme peut être causé par une défaillance.

Un test confirme ou écarte une cause.

Une procédure résout un incident.

Étape 5 — 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.

Étape 6 — Exceptions

Ne pas redémarrer l’équipement si un bruit métallique est présent.

Étape 7 — Validation

Les techniciens testent le modèle sur des incidents historiques.

Ils vérifient :

si les règles sont exactes ;
si l’ordre des tests est logique ;
si les exceptions sont complètes ;
si le vocabulaire est compréhensible.

Les connaissances validées pourront ensuite être organisées dans une ontologie ou un graphe.

Acquisition manuelle et acquisition automatique

L’acquisition peut être manuelle, automatique ou hybride.

Acquisition manuelle

Elle repose principalement sur :

les entretiens ;
l’observation ;
les ateliers ;
l’analyse humaine des documents.

Elle permet une compréhension fine du domaine, mais elle demande du temps.

Acquisition automatique

Des outils peuvent extraire depuis les textes :

des entités ;
des mots-clés ;
des catégories ;
des relations ;
des événements ;
des règles potentielles.

Les techniques utilisées peuvent inclure :

le traitement automatique du langage ;
la reconnaissance d’entités ;
la classification ;
l’analyse sémantique ;
les modèles de langage.

Acquisition hybride

L’approche hybride combine l’automatisation et la validation humaine.

Exemple :

un modèle analyse un corpus ;
il propose des concepts ;
il détecte des relations ;
un expert vérifie les propositions ;
le Knowledge Engineer organise le modèle ;
les résultats sont testés.

Cette approche est généralement plus réaliste que l’automatisation complète.

Le rôle des LLM

Les modèles de langage peuvent assister plusieurs étapes :

résumer des entretiens ;
extraire des termes ;
proposer des catégories ;
reformuler des définitions ;
identifier des relations ;
générer des règles candidates ;
comparer des documents ;
détecter des contradictions potentielles.

Ils présentent toutefois plusieurs risques :

invention de concepts ;
mauvaise interprétation ;
simplification excessive ;
mélange de plusieurs contextes ;
oubli des exceptions ;
absence de source fiable.

Les résultats doivent donc être considérés comme des propositions à valider.

Cette question est approfondie dans Knowledge Engineering, RAG et LLM.

Comment savoir si l’acquisition est suffisante ?

L’acquisition n’est jamais totalement terminée.

Elle devient suffisante lorsque le système peut répondre correctement aux questions prioritaires.

Il faut notamment vérifier :

la couverture des cas fréquents ;
la prise en compte des cas critiques ;
la cohérence des concepts ;
la précision des règles ;
la présence des exceptions ;
la traçabilité des sources ;
la validation par les experts.

Les tests doivent porter sur des cas réels, pas uniquement sur des exemples simples.

Erreurs fréquentes

Commencer par l’outil

Choisir une base graphe ou une technologie avant de définir le besoin conduit souvent à une modélisation inutilement complexe.

Interroger un seul expert

Un seul point de vue peut être incomplet ou trop personnel.

Se limiter aux documents

Les pratiques réelles contiennent souvent des connaissances absentes des procédures.

Recueillir des définitions sans analyser les décisions

Les connaissances importantes se trouvent souvent dans les critères, les règles et les exceptions.

Formaliser trop rapidement

Une règle simplifiée peut déformer l’expertise.

Ignorer les contradictions

Les divergences doivent être analysées et documentées.

Oublier les sources

Une connaissance sans origine ni date devient difficile à vérifier et à maintenir.

Considérer les propositions d’un LLM comme validées

Un résultat plausible n’est pas nécessairement correct.

À retenir

L’acquisition des connaissances transforme des sources dispersées en éléments explicites et structurés.
Les connaissances peuvent provenir des experts, des documents, des données, des pratiques et des systèmes existants.
La collecte d’informations ne suffit pas : il faut identifier les concepts, les relations, les règles et les exceptions.
Les cas concrets révèlent souvent davantage de connaissances que les questions générales.
L’entretien doit être complété par l’observation, l’analyse documentaire et la comparaison de situations.
Les divergences entre experts doivent être étudiées plutôt que supprimées.
Chaque connaissance importante doit conserver sa source, sa date et son champ d’application.
Les LLM peuvent assister l’acquisition, mais la validation humaine reste indispensable.
L’acquisition doit être guidée par les questions auxquelles le futur système devra répondre.
Les connaissances recueillies pourront ensuite être organisées grâce aux méthodes de représentation des connaissances.

Vérifiez votre compréhension

Quelle différence existe-t-il entre collecte d’informations et acquisition des connaissances ?

La collecte rassemble des contenus. L’acquisition cherche à en extraire les concepts, les relations, les règles, les critères et les exceptions utiles à un système.

Pourquoi faut-il étudier des cas concrets ?

Parce qu’ils permettent aux experts d’expliquer plus précisément leur raisonnement, leurs décisions et les informations qu’ils utilisent.

Pourquoi les documents ne suffisent-ils pas ?

Parce qu’ils peuvent être incomplets, anciens ou différents de la pratique réelle. Une partie de l’expertise reste également tacite.

Comment identifier une règle métier ?

En demandant dans quelles conditions une décision est prise, quels critères sont nécessaires et quelles exceptions peuvent modifier la conclusion.

Pourquoi faut-il conserver la source d’une connaissance ?

Pour pouvoir la vérifier, l’expliquer, la mettre à jour et déterminer son niveau de fiabilité.

Quel rôle peuvent jouer les LLM ?

Ils peuvent proposer des concepts, relations et règles à partir des textes, mais leurs résultats doivent être contrôlés et validés.

Questions fréquentes

Qu’est-ce qu’un expert du domaine ?

Un expert du domaine est une personne qui possède une expérience et une connaissance approfondies du sujet traité.

Combien d’experts faut-il interroger ?

Il n’existe pas de nombre universel. Il faut couvrir les principales pratiques, responsabilités et situations du domaine, tout en comparant plusieurs points de vue lorsque cela est possible.

Une procédure constitue-t-elle une connaissance ?

Oui, elle peut contenir des connaissances explicites. Elle ne représente toutefois pas nécessairement toute la connaissance utilisée dans la pratique.

Peut-on acquérir des connaissances uniquement à partir de données ?

Les données peuvent révéler des régularités, mais leur interprétation nécessite souvent une expertise métier et une connaissance du contexte.

Comment traiter un désaccord entre experts ?

Il faut identifier l’origine du désaccord, le contexte de chaque règle et les preuves disponibles. Plusieurs règles peuvent parfois être valides dans des situations différentes.

L’acquisition des connaissances est-elle réalisée une seule fois ?

Non. Elle doit être poursuivie lorsque le domaine, les procédures, les produits ou les besoins évoluent.

Continuer le parcours

Étape précédente

Distinguer la connaissance tacite de la connaissance explicite

Étape suivante

Après avoir recueilli les connaissances, il faut apprendre à les organiser sous une forme compréhensible par un système.

➡️ Représentation des connaissances : méthodes et modèles

Revenir au sommaire

Voir le parcours complet de Knowledge Engineering