Connaissance tacite et connaissance explicite : quelles différences ?
Une partie de ce que nous savons peut être facilement formulée, écrite et transmise. Une autre partie repose sur l’expérience, les habitudes, les perceptions et les gestes acquis au fil du temps.
Cette distinction oppose généralement la connaissance explicite à la connaissance tacite.
La connaissance explicite peut être décrite dans une procédure, un manuel, une règle ou une base de données. La connaissance tacite est plus difficile à exprimer, car elle est souvent intégrée à la manière d’agir d’une personne.
Cette différence est fondamentale en Knowledge Engineering. Avant de représenter une connaissance dans une base de connaissances, une ontologie ou un système expert, il faut d’abord parvenir à l’identifier et à la formaliser.
Ce que vous allez comprendre
À la fin de cet article, vous saurez :
- distinguer une connaissance tacite d’une connaissance explicite ;
- reconnaître leurs différentes formes ;
- comprendre pourquoi l’expertise ne se réduit pas à des documents ;
- identifier les difficultés liées à la formalisation ;
- comprendre comment un ingénieur des connaissances recueille le savoir d’un expert ;
- relier ces notions à l’intelligence artificielle et aux LLM.
Qu’est-ce qu’une connaissance explicite ?
Une connaissance explicite est une connaissance qui peut être formulée, enregistrée et transmise sous une forme compréhensible.
Elle peut apparaître dans :
- un manuel ;
- une procédure ;
- une règle ;
- une norme ;
- une fiche technique ;
- un rapport ;
- un tableau ;
- une base de données ;
- une formule ;
- une vidéo de formation ;
- un schéma.
Exemple :
Pour redémarrer l’équipement, maintenir le bouton principal pendant dix secondes.La connaissance est formulée de manière suffisamment précise pour être transmise à une autre personne.
Autre exemple :
Une facture est considérée comme échue lorsque sa date limite de paiement est dépassée.Cette connaissance peut être intégrée dans un logiciel de gestion ou dans un système expert.
Caractéristiques de la connaissance explicite
Une connaissance explicite est généralement :
- formulée ;
- documentée ;
- partageable ;
- transmissible ;
- stockable ;
- consultable ;
- modifiable ;
- réutilisable.
Elle peut être copiée d’un système à un autre ou transformée en règle informatique.
Cependant, le fait qu’une connaissance soit écrite ne garantit pas qu’elle soit exacte, complète ou encore valide.
Une procédure peut être :
- ancienne ;
- ambiguë ;
- contradictoire ;
- trop générale ;
- différente de la pratique réelle ;
- inadaptée à certains cas particuliers.
Le Knowledge Engineering ne consiste donc pas seulement à collecter des documents. Il faut également analyser leur signification, leurs conditions d’application et leur niveau de fiabilité.
Qu’est-ce qu’une connaissance tacite ?
Une connaissance tacite est une connaissance difficile à formuler complètement.
Elle repose souvent sur :
- l’expérience ;
- l’intuition professionnelle ;
- l’observation ;
- les habitudes ;
- la perception ;
- la mémoire des situations ;
- la maîtrise d’un geste ;
- la reconnaissance de configurations particulières.
Un professionnel expérimenté peut savoir quoi faire sans être capable d’expliquer immédiatement toutes les étapes de son raisonnement.
Exemple :
Un mécanicien reconnaît qu’un moteur fonctionne anormalement en écoutant son bruit.
Il possède une connaissance réelle, mais celle-ci n’est pas encore représentée sous la forme d’une règle précise.
Il peut avoir du mal à expliquer :
- quel son exact l’alerte ;
- quelle différence il perçoit ;
- quelles expériences antérieures il mobilise ;
- pourquoi il élimine certaines causes ;
- quel niveau de confiance il attribue à son diagnostic.
Exemples de connaissances tacites
La connaissance tacite apparaît dans de nombreux métiers.
En maintenance
Un technicien reconnaît une vibration inhabituelle avant même qu’un capteur ne déclenche une alerte.
En médecine
Un médecin estime qu’un patient semble plus fragile que ne l’indiquent ses seuls résultats biologiques.
En droit
Un avocat reconnaît qu’un dossier présente un risque particulier en rapprochant plusieurs détails qui, pris séparément, semblent peu importants.
En vente
Un commercial perçoit qu’un client hésite pour une raison différente de celle qu’il exprime.
En rédaction
Un rédacteur sent qu’une phrase est maladroite sans être immédiatement capable d’identifier la règle stylistique concernée.
En navigation
Une personne expérimentée modifie sa trajectoire en observant simultanément le vent, la mer, le comportement du bateau et l’évolution du ciel.
En cuisine
Un cuisinier sait qu’une pâte possède la bonne texture en la touchant, sans mesurer précisément sa composition.
Dans chaque cas, l’expertise ne repose pas uniquement sur des règles écrites.
Différence entre connaissance tacite et connaissance explicite
| Connaissance explicite | Connaissance tacite |
|---|---|
| Peut être formulée | Difficile à formuler complètement |
| Peut être écrite | Repose souvent sur l’expérience |
| Peut être stockée dans un document | Se manifeste dans l’action |
| Se transmet par des supports | Se transmet souvent par la pratique |
| Peut être intégrée directement dans un système | Doit d’abord être explicitée |
| Est généralement plus facile à vérifier | Peut dépendre fortement du contexte |
| Peut être partagée à grande échelle | Reste souvent liée à une personne |
La distinction n’est toutefois pas absolue.
Une même connaissance peut contenir une partie explicite et une partie tacite.
Exemple :
La procédure indique de vérifier la pression.Mais l’expert sait également :
Dans ce type de situation, une pression légèrement normale peut malgré tout révéler un problème si le bruit du système a changé.La procédure officielle est explicite. L’interprétation experte reste tacite.
Pourquoi l’expertise ne se réduit-elle pas à des documents ?
Une organisation peut disposer de procédures très détaillées tout en dépendant fortement de quelques personnes expérimentées.
Cela s’explique par plusieurs raisons.
Les documents simplifient la réalité
Une procédure décrit généralement les situations les plus fréquentes. Elle ne peut pas toujours prévoir tous les cas particuliers.
Les experts utilisent le contexte
Une règle peut être correcte dans une situation et inadaptée dans une autre.
L’expert tient compte de facteurs parfois absents du document :
- l’historique ;
- l’urgence ;
- le profil du client ;
- l’état du matériel ;
- les interactions avec d’autres problèmes ;
- les conséquences possibles.
Les pratiques évoluent plus vite que les procédures
Les professionnels adaptent parfois leur travail avant que la documentation ne soit mise à jour.
Certains raisonnements sont automatisés par l’expérience
Une personne expérimentée ne décompose plus consciemment toutes les étapes de sa décision.
Elle reconnaît directement une configuration.
Les documents peuvent être incomplets
Certaines connaissances sont considérées comme évidentes par les experts et ne sont donc jamais écrites.
Un exemple détaillé
Imaginons un technicien chargé de diagnostiquer une machine.
La procédure officielle indique :
1. Vérifier l’alimentation.
2. Contrôler la température.
3. Examiner le code d’erreur.
4. Redémarrer la machine.Le technicien expérimenté ajoute mentalement plusieurs connaissances :
Si le code d’erreur apparaît uniquement le matin, vérifier l’humidité.Si la machine produit un bruit métallique avant l’arrêt, ne pas la redémarrer.Si le problème survient après un changement de série, contrôler le paramétrage.Si le voyant clignote irrégulièrement, le problème peut venir du connecteur et non du module principal.Ces connaissances ne figurent pas nécessairement dans la procédure.
Elles proviennent de l’expérience accumulée.
Le travail d’acquisition des connaissances consiste à faire apparaître ces éléments cachés.
Pourquoi la connaissance tacite est-elle difficile à formaliser ?
Plusieurs obstacles rendent l’explicitation difficile.
L’expert ne sait pas toujours expliquer ce qu’il sait
Une personne peut réussir une tâche sans pouvoir décrire précisément son raisonnement.
Elle peut répondre :
- « Je le sens. »
- « Je le vois tout de suite. »
- « Avec l’expérience, on le sait. »
- « Cela dépend de la situation. »
- « Je ne peux pas vraiment l’expliquer. »
Ces réponses ne signifient pas que la connaissance n’existe pas. Elles indiquent qu’elle n’a pas encore été décomposée.
L’expert généralise après coup
Lorsqu’on lui demande d’expliquer une décision, l’expert peut produire une justification simplifiée qui ne correspond pas exactement au processus réellement utilisé.
Il reconstruit parfois son raisonnement après l’action.
Les connaissances sont contextuelles
Une règle peut dépendre :
- du type de client ;
- du moment ;
- du niveau de risque ;
- de l’état du système ;
- d’événements antérieurs ;
- de plusieurs signaux combinés.
Une formulation trop générale peut donc devenir fausse.
Plusieurs experts peuvent être en désaccord
Deux spécialistes peuvent résoudre le même problème de manière différente.
Cela peut révéler :
- des écoles de pensée ;
- des niveaux d’expérience différents ;
- des contextes d’application différents ;
- des préférences personnelles ;
- des contradictions réelles.
Le Knowledge Engineering ne doit pas masquer ces désaccords. Il doit les identifier et les représenter correctement.
L’expert peut oublier les cas ordinaires
Une action devenue automatique n’est plus perçue comme une étape distincte.
L’expert peut donc omettre des détails essentiels pour un débutant ou pour un système informatique.
Comment transformer une connaissance tacite en connaissance explicite ?
La formalisation ne consiste pas à demander simplement à l’expert de « tout expliquer ».
Il faut utiliser plusieurs méthodes complémentaires.
Les entretiens
L’entretien permet d’interroger l’expert sur :
- les concepts importants ;
- les règles ;
- les exceptions ;
- les erreurs fréquentes ;
- les critères de décision ;
- les situations difficiles.
Une question trop générale produit souvent une réponse abstraite.
Au lieu de demander :
Comment réalisez-vous un diagnostic ?
Il est plus efficace de demander :
Décrivez le dernier cas dans lequel vous avez hésité entre deux causes possibles.
Les situations concrètes font émerger davantage de connaissances.
L’observation
Observer un professionnel en situation permet d’identifier :
- les gestes ;
- l’ordre réel des actions ;
- les informations consultées ;
- les vérifications informelles ;
- les adaptations ;
- les étapes non documentées.
L’écart entre la procédure officielle et la pratique réelle devient alors visible.
L’analyse de cas
L’expert peut être invité à comparer plusieurs situations :
- un cas normal ;
- un cas exceptionnel ;
- un échec ;
- une réussite ;
- un cas ambigu ;
- un cas limite.
Cette comparaison aide à faire apparaître les critères de décision.
La verbalisation simultanée
L’expert décrit ce qu’il pense pendant qu’il réalise une tâche.
Exemple :
Je commence par vérifier ce voyant, car s’il clignote rapidement, le problème ne vient probablement pas de l’alimentation.Cette méthode permet de recueillir une partie du raisonnement au moment où il se produit.
La reconstruction rétrospective
Après une intervention, l’expert reprend chaque étape :
- Qu’avez-vous observé ?
- Quelle hypothèse avez-vous formulée ?
- Quelle hypothèse avez-vous rejetée ?
- Quelle information a modifié votre décision ?
- Quel risque vouliez-vous éviter ?
Cette méthode produit une trace plus précise du raisonnement.
Les cartes conceptuelles
Une carte conceptuelle représente visuellement :
- les concepts ;
- les sous-concepts ;
- les relations ;
- les causes ;
- les conséquences ;
- les exceptions.
Elle permet à l’expert de corriger plus facilement une représentation que de produire directement une longue explication.
Les scénarios et simulations
L’expert peut être confronté à une situation fictive.
On lui demande :
- ce qu’il ferait ;
- quelles informations il rechercherait ;
- ce qui modifierait sa décision ;
- à quel moment il demanderait un avis supplémentaire.
Les scénarios révèlent les règles conditionnelles.
Du récit expert à la règle
Prenons cette déclaration :
Quand le client appelle plusieurs fois dans la même journée, ce n’est pas toujours parce que le problème est grave. Mais s’il a déjà suivi la procédure et que son activité est bloquée, je traite le dossier en priorité.
Cette connaissance peut être décomposée.
Concepts
- client ;
- appel ;
- procédure ;
- activité ;
- blocage ;
- priorité.
Faits
Le client a appelé plusieurs fois.Le client a suivi la procédure.L’activité du client est bloquée.Règle
SI le client a déjà suivi la procédure
ET si son activité est bloquée
ALORS le dossier doit être traité en priorité.Exception
Le nombre d’appels ne suffit pas, à lui seul, à déterminer la priorité.Cette transformation relève de la représentation des connaissances.
Formaliser sans déformer
La formalisation présente un risque : simplifier excessivement la connaissance.
Une règle comme :
SI le client appelle trois fois
ALORS le dossier est prioritaire.peut sembler pratique, mais elle déforme l’expertise initiale.
Le véritable critère repose sur le blocage de l’activité et sur les actions déjà réalisées, non sur le nombre d’appels.
Le Knowledge Engineer doit donc vérifier :
- si la règle représente réellement la pratique ;
- si les conditions sont complètes ;
- si les exceptions sont identifiées ;
- si le vocabulaire est précis ;
- si plusieurs experts valident la formulation.
Du savoir tacite à l’ontologie
Une partie des connaissances recueillies peut être représentée dans une ontologie informatique.
Exemple :
Incident
├── possède un niveau de gravité
├── affecte une activité
├── concerne un client
└── nécessite une interventionRelations :
Un incident bloque une activité.Un client réalise une procédure.Une procédure tente de résoudre un incident.Un incident bloquant possède une priorité élevée.L’ontologie définit le vocabulaire et les relations.
Les cas concrets peuvent ensuite être représentés dans un graphe de connaissances.
Connaissance tacite et graphe de connaissances
Un graphe peut rendre visibles des relations auparavant dispersées.
Exemple :
Incident 458
├── concerne → Client Alpha
├── affecte → Système de paiement
├── bloque → Activité commerciale
├── persiste après → Procédure de redémarrage
└── possède → Priorité élevéeLe graphe ne capture pas automatiquement toute l’expérience humaine.
Il fournit toutefois une structure dans laquelle les connaissances explicitées peuvent être organisées et interrogées.
Connaissance tacite et système expert
Un système expert utilise généralement des faits et des règles explicites.
Exemple :
SI l’activité est bloquée
ET si la procédure standard a échoué
ALORS attribuer une priorité élevée.La difficulté principale consiste donc à transformer une expertise tacite en règles suffisamment précises.
Cependant, toutes les connaissances tacites ne peuvent pas être converties en règles simples.
Certaines reposent sur :
- des perceptions fines ;
- des combinaisons de nombreux indices ;
- une forte incertitude ;
- un contexte changeant ;
- une expérience difficile à décomposer.
Dans ces situations, une approche statistique ou hybride peut être plus adaptée.
Connaissance tacite et intelligence artificielle
Les systèmes d’intelligence artificielle peuvent aider à détecter des régularités dans les décisions d’experts.
Par exemple, un modèle peut analyser :
- des dossiers historiques ;
- les décisions prises ;
- les caractéristiques des situations ;
- les résultats obtenus.
Il peut alors identifier des facteurs souvent associés à une décision.
Cependant, cette corrélation ne fournit pas nécessairement une connaissance explicite.
Le système peut constater qu’un ensemble de variables conduit souvent à une conclusion sans être capable de produire une règle claire et validée.
Le Knowledge Engineering cherche à rendre cette connaissance :
- compréhensible ;
- explicable ;
- contrôlable ;
- modifiable ;
- validable.
Les LLM peuvent-ils extraire les connaissances tacites ?
Les modèles de langage peuvent aider à analyser :
- des entretiens ;
- des comptes rendus ;
- des procédures ;
- des échanges professionnels ;
- des rapports d’incidents.
Ils peuvent proposer :
- des concepts ;
- des relations ;
- des règles ;
- des résumés ;
- des catégories ;
- des exceptions possibles.
Mais ils ne garantissent pas que la représentation produite corresponde réellement à l’expertise.
Un LLM peut :
- simplifier excessivement ;
- inventer une règle ;
- mélanger plusieurs contextes ;
- ignorer une exception ;
- présenter une hypothèse comme un fait.
Les propositions doivent donc être validées par les experts du domaine.
Cette complémentarité est étudiée dans l’article Knowledge Engineering, RAG et LLM.
Peut-on tout expliciter ?
Non.
Certaines connaissances restent partiellement tacites.
Un expert peut améliorer son explication, mais il n’est pas toujours possible de convertir intégralement son expérience en règles.
Plusieurs limites existent :
- la perception sensorielle ;
- les gestes techniques ;
- les décisions prises sous incertitude ;
- les situations inédites ;
- les intuitions fondées sur des milliers de cas ;
- les connaissances sociales ou relationnelles.
L’objectif n’est donc pas nécessairement de tout formaliser.
Il faut surtout formaliser ce qui est utile pour le système à construire.
Choisir les connaissances à formaliser
La formalisation possède un coût.
Il faut donc donner la priorité aux connaissances qui sont :
- importantes pour la décision ;
- fréquemment utilisées ;
- difficiles à remplacer ;
- exposées à un risque de perte ;
- nécessaires à la formation ;
- sources d’erreurs ;
- utiles à plusieurs personnes ;
- exploitables par un système.
Une connaissance rare mais critique peut être plus importante qu’une grande quantité d’informations ordinaires.
Le risque de perte des connaissances
Une organisation devient vulnérable lorsque des connaissances essentielles sont détenues par une seule personne.
Le départ d’un expert peut entraîner la perte de :
- critères de décision ;
- raccourcis efficaces ;
- connaissances historiques ;
- exceptions ;
- contacts ;
- méthodes de diagnostic ;
- solutions informelles.
Le Knowledge Engineering contribue à réduire ce risque en organisant :
- l’identification des connaissances critiques ;
- leur acquisition ;
- leur validation ;
- leur représentation ;
- leur transmission ;
- leur maintenance.
Connaissance tacite et Knowledge Management
Le Knowledge Management et le Knowledge Engineering abordent cette question sous deux angles différents.
Le Knowledge Management cherche notamment à favoriser :
- les communautés de pratique ;
- le partage d’expérience ;
- le mentorat ;
- la documentation ;
- la transmission entre collaborateurs.
Le Knowledge Engineering cherche davantage à :
- définir les concepts ;
- formaliser les règles ;
- construire des modèles ;
- représenter les relations ;
- rendre les connaissances exploitables par des systèmes.
Les deux approches peuvent être complémentaires.
Erreurs fréquentes
Croire que toute connaissance peut être écrite facilement
Une partie importante de l’expertise reste intégrée à la pratique.
Demander uniquement aux experts de rédiger une procédure
Les experts ne perçoivent pas toujours toutes les étapes de leur propre raisonnement.
Confondre discours et pratique réelle
Ce qu’une personne dit faire ne correspond pas toujours exactement à ce qu’elle fait.
Formaliser trop rapidement
Une règle rédigée trop tôt peut masquer des exceptions importantes.
Interroger un seul expert
Un seul point de vue peut être incomplet ou dépendre d’une pratique personnelle.
Chercher à tout formaliser
Toutes les connaissances ne sont pas utiles au système.
Utiliser un LLM sans validation humaine
Le modèle peut produire une représentation plausible mais incorrecte.
Exemple pratique
Imaginons une entreprise qui souhaite créer un assistant pour aider ses équipes commerciales.
Connaissance explicite disponible
- catalogue des produits ;
- tarifs ;
- fiches techniques ;
- conditions contractuelles ;
- procédures de commande.
Connaissance tacite des commerciaux
- reconnaître un client uniquement intéressé par le prix ;
- identifier les objections non exprimées ;
- choisir le bon moment pour présenter une option ;
- détecter un risque de perte du client ;
- adapter le vocabulaire au niveau technique de l’interlocuteur.
Travail de formalisation
L’équipe peut analyser des entretiens commerciaux et identifier des signaux récurrents.
Exemple :
SI le client demande immédiatement le prix
ET ne pose aucune question sur les caractéristiques
ALORS son critère principal peut être budgétaire.Cette règle reste une hypothèse. Elle doit être complétée par d’autres signaux et validée sur des cas réels.
Le système ne remplace pas le commercial. Il lui fournit des informations structurées et des recommandations contrôlées.
À retenir
- Une connaissance explicite peut être formulée, documentée et transmise.
- Une connaissance tacite repose largement sur l’expérience et la pratique.
- L’expertise professionnelle combine généralement ces deux formes.
- Une procédure ne décrit pas toujours la réalité complète du travail.
- L’acquisition des connaissances vise à faire apparaître les critères, règles et exceptions implicites.
- Les entretiens seuls ne suffisent pas toujours : l’observation et l’analyse de cas sont essentielles.
- La formalisation doit éviter de simplifier ou de déformer l’expertise.
- Toutes les connaissances tacites ne peuvent pas être intégralement explicitées.
- Les LLM peuvent assister l’extraction, mais les experts doivent valider les résultats.
- La connaissance formalisée peut ensuite être intégrée dans une ontologie, un graphe ou un système expert.
Vérifiez votre compréhension
Quelle différence existe-t-il entre connaissance tacite et connaissance explicite ?
La connaissance explicite peut être formulée et enregistrée. La connaissance tacite repose davantage sur l’expérience, la perception et les habitudes d’action.
Pourquoi un expert ne peut-il pas toujours expliquer ce qu’il sait ?
Parce qu’une partie de son raisonnement est devenue automatique ou repose sur la reconnaissance de situations accumulées au fil de l’expérience.
Une procédure contient-elle toute la connaissance d’un métier ?
Non. Elle décrit généralement les étapes principales, mais elle ne contient pas toujours les adaptations, les exceptions et les critères implicites.
Comment recueillir une connaissance tacite ?
Par des entretiens, l’observation, l’analyse de cas, la verbalisation, les simulations et la comparaison de décisions.
Peut-on transformer toute connaissance tacite en règles ?
Non. Certaines connaissances restent difficiles à décomposer ou dépendent fortement du contexte et de la perception.
Questions fréquentes
Qui a introduit la notion de connaissance tacite ?
La notion est notamment associée au philosophe et scientifique Michael Polanyi, qui a souligné qu’une personne peut savoir davantage qu’elle ne peut exprimer.
Une compétence est-elle une connaissance tacite ?
Une compétence combine généralement des connaissances, des méthodes, de l’expérience et une capacité à agir. Elle peut donc contenir une forte dimension tacite.
Une vidéo rend-elle une connaissance explicite ?
Elle peut rendre certains gestes observables, mais elle n’explique pas nécessairement les critères de décision ou les perceptions de l’expert.
Une connaissance tacite peut-elle être transmise ?
Oui, notamment par la pratique, l’imitation, le mentorat, l’observation et l’accompagnement.
Une intelligence artificielle peut-elle posséder une connaissance tacite ?
Une IA peut apprendre des régularités difficiles à expliquer, mais le terme « connaissance tacite » est principalement utilisé pour désigner une dimension de l’expérience humaine.
Pourquoi formaliser les connaissances tacites ?
Pour faciliter leur transmission, éviter leur perte, améliorer les décisions et permettre leur utilisation dans des systèmes informatiques.
Poursuivre le parcours
Après avoir distingué les connaissances tacites et explicites, l’étape suivante consiste à comprendre comment les recueillir méthodiquement.
➡️ Acquisition des connaissances : méthodes et processus
Vous pouvez également consulter :