Comment construire une base de connaissances : méthode en 12 étapes

Construire une base de connaissances ne consiste pas à déposer tous les documents d’une organisation dans un même dossier.

Une véritable base de connaissances doit permettre de retrouver et d’utiliser des informations fiables dans un contexte précis.

Elle peut servir à :

répondre à des questions ;
guider un professionnel ;
recommander une action ;
expliquer une règle ;
diagnostiquer un problème ;
alimenter un système RAG ;
transmettre une expertise ;
fournir une mémoire à un agent d’intelligence artificielle.

La difficulté principale n’est pas le stockage. Elle consiste à sélectionner, organiser, valider et maintenir les connaissances utiles.

Une base de connaissances efficace ne contient pas nécessairement beaucoup de contenu. Elle contient les bonnes connaissances, organisées pour répondre à des besoins définis.

Ce guide présente une méthode progressive, applicable avec de simples fichiers Markdown, un tableur, une base documentaire ou une architecture plus avancée.

Ce que vous allez construire

Nous prendrons l’exemple d’une base destinée à recommander des formations selon les compétences d’un participant.

Elle devra répondre à des questions comme :

quel niveau possède le participant ?
quels prérequis exige une formation ?
quelle formation permet d’acquérir le niveau manquant ?
quelle certification peut être préparée ?
quelle source justifie la recommandation ?

Le même processus peut être adapté à :

un support technique ;
une documentation produit ;
un domaine juridique ;
une activité de maintenance ;
une base réglementaire ;
une FAQ ;
un assistant interne.

Étape 1 — Définir le problème

Commencez par une tâche précise.

Objectif trop vague

Créer une base contenant toutes les connaissances de l’entreprise.

Cet objectif ne permet pas de déterminer :

les contenus prioritaires ;
les utilisateurs ;
le niveau de détail ;
les critères de réussite.

Objectif opérationnel

Permettre à un conseiller de recommander un parcours de formation adapté au niveau d’un participant.

Cet objectif définit déjà :

un utilisateur : le conseiller ;
une action : recommander ;
un domaine : les formations ;
un objet de décision : le parcours ;
une information nécessaire : le niveau du participant.

Fiche de cadrage

Rédigez une fiche simple :

Problème :
Les conseillers ne savent pas toujours quelle formation recommander.

Utilisateurs :
Conseillers pédagogiques et participants.

Décision attendue :
Proposer la prochaine formation adaptée.

Périmètre :
Formations SEO de niveau débutant à avancé.

Exclusions :
Gestion administrative et paiement.

Résultat attendu :
Une recommandation accompagnée de ses prérequis et de ses sources.

Étape 2 — Définir les questions auxquelles répondre

Les questions constituent le véritable cahier des charges de la base.

Exemples :

Quel niveau possède le participant ?
Quel niveau exige la formation ?
Le participant possède-t-il ce prérequis ?
Quelle formation permet d’acquérir le niveau manquant ?
Quelle certification valide la compétence ?
Quelle règle justifie la recommandation ?
Quelle est la source de cette règle ?

Ces questions sont parfois appelées questions de compétence.

Elles servent à :

délimiter le projet ;
identifier les connaissances nécessaires ;
concevoir la structure ;
construire les tests ;
mesurer la couverture.

Étape 3 — Identifier les utilisateurs

Une même connaissance ne sera pas présentée de la même manière à tous les utilisateurs.

Conseiller expérimenté

Il peut avoir besoin :

des règles détaillées ;
des exceptions ;
des sources ;
des cas particuliers.

Participant

Il souhaite plutôt :

une recommandation simple ;
l’explication du prérequis ;
la prochaine étape ;
un lien vers la formation.

Administrateur

Il doit pouvoir :

ajouter une formation ;
modifier une règle ;
archiver un contenu ;
consulter les versions.

La structure de la base doit tenir compte de ces usages.

Étape 4 — Recenser les sources

Les connaissances peuvent provenir de plusieurs endroits.

Source	Connaissances possibles
Experts	Raisonnement, exceptions, cas complexes
Documents	Procédures, définitions, règles officielles
Bases de données	Faits, historiques, identifiants
Tableurs	Catalogues, listes, correspondances
Applications	Statuts, règles déjà programmées
Utilisateurs	Questions fréquentes et difficultés
Cas passés	Décisions et résultats réels

Pour notre exemple, les sources pourraient être :

catalogue des formations ;
règlement pédagogique ;
dossiers des participants ;
entretiens avec les formateurs ;
historique des inscriptions ;
descriptions des certifications.

Registre des sources

Créez un tableau :

Source	Responsable	Date	Fiabilité	Statut
Catalogue 2026	Service formation	2026	Élevée	Actif
Ancien catalogue	Service formation	2024	Faible	Obsolète
Entretien avec un formateur	Équipe projet	2026	À valider	Brouillon
Règlement pédagogique	Direction	2026	Élevée	Actif

Cette étape évite de traiter de la même manière une règle officielle et une remarque non vérifiée.

Étape 5 — Recueillir les connaissances

L’acquisition des connaissances peut combiner plusieurs méthodes.

Analyse documentaire

Recherchez :

les termes importants ;
les définitions ;
les conditions ;
les exceptions ;
les versions ;
les responsabilités ;
les dates.

Entretiens

Posez des questions concrètes :

comment déterminez-vous le niveau d’un participant ?
dans quel cas acceptez-vous une inscription sans prérequis ?
quelle erreur est la plus fréquente ?
quelle information vous fait changer de recommandation ?
pouvez-vous décrire un cas récent ?

Analyse des cas

Comparez :

une recommandation correcte ;
une recommandation incorrecte ;
un cas simple ;
une exception ;
un dossier incomplet.

Étape 6 — Construire un vocabulaire contrôlé

Listez les termes utilisés.

Exemple :

Participant
Formation
Session
Compétence
Niveau
Prérequis
Évaluation
Certification
Formateur

Définissez-les précisément.

Exemple de fiche

Terme :
Formation

Définition :
Programme pédagogique visant le développement d’une ou plusieurs compétences.

À ne pas confondre avec :
Session de formation.

Synonymes admis :
Programme.

Source :
Catalogue officiel.

Statut :
Validé.

Distinguer formation et session

Formation :
Programme général.

Session :
Mise en œuvre datée d’une formation.

Cette distinction évite d’associer par erreur une date au concept général de formation.

Étape 7 — Choisir une structure

La structure dépend du besoin.

Documentation simple

Convient à :

une FAQ ;
des procédures ;
des articles ;
un petit corpus.

Taxonomie

Convient pour :

classer les contenus ;
créer des catégories ;
organiser un menu ;
filtrer les documents.

Ontologie

Convient pour :

définir les concepts ;
représenter plusieurs types de relations ;
ajouter des contraintes ;
harmoniser les données.

Graphe de connaissances

Convient pour :

relier des entités ;
suivre des parcours ;
réunir plusieurs sources ;
répondre à des questions relationnelles.

Base de règles

Convient pour :

appliquer des conditions ;
produire des conclusions ;
justifier une décision.

Index vectoriel

Convient pour :

rechercher dans des textes ;
gérer les synonymes ;
alimenter un RAG.

Une base peut combiner plusieurs structures.

Étape 8 — Concevoir le modèle minimal

Pour notre exemple, le modèle minimal contient cinq concepts :

Participant
Formation
Compétence
Niveau
Certification

Relations :

Participant → possède → Compétence

Formation → développe → Compétence

Formation → exige → Niveau

Certification → valide → Compétence

Propriétés :

Formation
- titre
- durée
- niveau
- prix
- modalité

Le modèle doit être assez riche pour répondre aux questions, mais pas davantage.

Étape 9 — Formaliser les règles

Une base de connaissances opérationnelle contient souvent des règles.

Règle 1

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

Règle 2

SI le participant ne possède pas le niveau requis
ALORS rechercher une formation qui développe ce niveau.

Règle 3

SI le niveau du participant est inconnu
ALORS demander une évaluation avant de recommander une formation.

Chaque règle doit être documentée.

Fiche de règle

Identifiant :
REGLE-FORM-001

Intitulé :
Éligibilité selon le niveau.

Condition :
Le niveau du participant est égal ou supérieur au niveau exigé.

Conclusion :
Le participant est éligible.

Exception :
Admission manuelle possible après validation pédagogique.

Source :
Règlement pédagogique 2026.

Statut :
Validé.

Date de révision :
Janvier 2027.

Étape 10 — Ajouter les contenus

Une fiche de connaissance peut être enregistrée en Markdown.

---
title: "Formation SEO avancée"
type: formation
niveau: avance
statut: valide
source: "Catalogue 2026"
---

# Formation SEO avancée

## Objectif

Développer les compétences nécessaires à la conception et au pilotage d’une stratégie SEO avancée.

## Prérequis

Posséder un niveau intermédiaire en SEO.

## Compétences développées

- audit technique ;
- stratégie sémantique ;
- maillage interne ;
- suivi de performance.

L’important est d’utiliser des champs cohérents.

Étape 11 — Ajouter les sources, dates et statuts

Une connaissance sans contexte devient rapidement difficile à utiliser.

Ajoutez au minimum :

la source ;
la date ;
la version ;
le statut ;
le responsable ;
la prochaine révision.

Exemple

source: "Règlement pédagogique 2026"
version: "2.1"
statut: "validé"
responsable: "Service formation"
date_validation: "2026-07-12"
date_revision: "2027-01-15"

Statuts recommandés

Brouillon
À valider
Validé
Publié
À réviser
Obsolète
Archivé

Un contenu obsolète ne doit pas être supprimé sans trace s’il a été utilisé dans des décisions antérieures.

Étape 12 — Construire les tests

Une base n’est pas terminée lorsque les contenus sont importés.

Elle doit être testée.

Cas 1 — Pré requis satisfait

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

Résultat attendu :

Marie est éligible.

Cas 2 — Pré requis insuffisant

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

Résultat attendu :

Recommander la formation intermédiaire.

Cas 3 — Niveau inconnu

Le niveau de Marie n’est pas renseigné.

Résultat attendu :

Demander une évaluation.

Cas 4 — Exception

Marie possède une expérience équivalente validée par un responsable pédagogique.

Résultat attendu :

Autoriser une validation manuelle.

Cas 5 — Source obsolète

La règle provient du règlement 2024.
Une version 2026 existe.

Résultat attendu :

Utiliser la version 2026.

Contrôler la qualité

Évaluez la base selon plusieurs dimensions.

Exactitude

Les connaissances sont-elles correctes ?

Couverture

Les questions prioritaires peuvent-elles être traitées ?

Cohérence

Deux règles se contredisent-elles ?

Fraîcheur

Les versions actives sont-elles identifiées ?

Traçabilité

Chaque règle importante possède-t-elle une source ?

Utilisabilité

Les utilisateurs comprennent-ils les réponses ?

Explicabilité

Le système peut-il justifier une recommandation ?

Exemple de réponse explicable

Recommandation :
Formation SEO intermédiaire.

Justification :
- Marie possède le niveau débutant.
- La formation avancée exige le niveau intermédiaire.
- La formation intermédiaire développe le niveau nécessaire.

Source :
Catalogue des formations 2026 et règlement pédagogique 2.1.

Organiser la gouvernance

Définissez les responsabilités.

Rôle	Responsabilité
Expert métier	Valider les connaissances
Responsable de source	Maintenir les documents
Knowledge Engineer	Structurer le modèle
Administrateur	Publier et gérer les accès
Utilisateur	Signaler les erreurs
Responsable qualité	Contrôler les révisions

Boucle de maintenance

Utilisation
  ↓
Erreur ou manque signalé
  ↓
Analyse
  ↓
Correction
  ↓
Validation
  ↓
Nouveau test
  ↓
Publication

Relier la base à un LLM

Une base structurée peut alimenter un assistant.

Question
  ↓
Identification des concepts
  ↓
Recherche dans la base
  ↓
Application des règles
  ↓
Sélection des sources
  ↓
LLM
  ↓
Réponse expliquée

Le LLM ne doit pas devenir la seule source de vérité.

Il peut :

comprendre la question ;
reformuler les connaissances ;
produire une réponse lisible ;
demander une information manquante.

La base fournit :

les faits ;
les règles ;
les relations ;
les sources ;
les versions.

Architecture minimale avec Markdown

Pour un petit projet :

content/
├── formations/
├── competences/
├── certifications/
├── regles/
└── sources/

Chaque fichier utilise un front matter homogène.

Cette architecture peut suffire avant l’adoption d’une base SQL, d’une ontologie ou d’un graphe.

Architecture hybride

Pour un projet plus avancé :

Documents
+
Métadonnées
+
Base structurée
+
Index vectoriel
+
Graphe
+
Moteur de règles
+
LLM

N’ajoutez une technologie que lorsqu’elle résout un problème constaté.

Checklist finale

Avant le déploiement, vérifiez :

[ ] le problème est clairement défini ;
[ ] les utilisateurs sont identifiés ;
[ ] les questions prioritaires sont documentées ;
[ ] les sources sont recensées ;
[ ] les concepts sont définis ;
[ ] les relations sont explicites ;
[ ] les règles possèdent une source ;
[ ] les exceptions sont représentées ;
[ ] les dates et versions sont conservées ;
[ ] des cas de test existent ;
[ ] les utilisateurs ont testé la base ;
[ ] les responsabilités de maintenance sont définies.

Erreurs fréquentes

Importer tous les documents sans sélection

Le volume augmente, mais la qualité ne progresse pas.

Commencer par la technologie

Le projet s’adapte artificiellement à l’outil.

Confondre document et connaissance

Le document constitue une source. La connaissance doit encore être identifiée et structurée.

Oublier les exceptions

Le système applique des règles trop générales.

Ne pas conserver les versions

Une règle ancienne peut être présentée comme actuelle.

Utiliser un seul expert

Le modèle peut reproduire un point de vue incomplet.

Ne pas tester les cas inconnus

Le système doit savoir signaler qu’il ne dispose pas d’informations suffisantes.

Ne pas organiser la maintenance

La base devient rapidement obsolète.

À retenir

Une base de connaissances part d’un problème précis.
Les questions prioritaires définissent son périmètre.
Les sources doivent être recensées et évaluées.
Le vocabulaire doit être harmonisé.
Le modèle minimal doit répondre à un premier cas utile.
Les règles doivent conserver leur source et leurs exceptions.
Les dates, versions et statuts sont indispensables.
Les tests doivent couvrir les cas normaux, incomplets et exceptionnels.
La gouvernance garantit la maintenance.
Un LLM peut exploiter la base, mais ne remplace pas sa structuration.

Continuer

Comprendre ce qu’est une base de connaissances

Découvrir la méthode complète d’ingénierie des connaissances

Comprendre les relations entre Knowledge Engineering, RAG et LLM