Comment gérer les sources, les versions et la provenance des connaissances ?

Une connaissance utile doit pouvoir répondre à trois questions :

D’où vient-elle ?
Quand est-elle valide ?
Pourquoi devons-nous lui faire confiance ?

Sans ces informations, une base de connaissances peut présenter :

une ancienne règle comme actuelle ;
une hypothèse comme un fait ;
un résumé comme une source primaire ;
une relation sans preuve ;
un document non validé comme une procédure officielle.

La provenance désigne l’ensemble des informations permettant de retracer l’origine, les transformations et les validations d’une connaissance.

Elle est essentielle dans :

les bases de connaissances ;
les graphes ;
les ontologies ;
les systèmes RAG ;
les moteurs de règles ;
les assistants utilisant un LLM.

Une connaissance sans provenance peut être utile pour explorer. Elle ne suffit pas pour justifier une décision.

Source, référence et provenance

Ces termes sont proches mais différents.

Source

Le document, la personne, la base ou le système dont provient l’information.

Exemples :

procédure officielle ;
manuel ;
entretien ;
base de données ;
règlement ;
rapport.

Référence

L’identification précise de la partie utilisée.

Exemple :

Procédure X200, version 4.2, page 12, section « Voyant rouge ».

Provenance

La provenance inclut davantage d’informations :

la source d’origine ;
le passage ;
la date ;
la méthode d’extraction ;
les transformations ;
les validations ;
la version ;
le niveau de confiance.

Exemple complet

statement:
  subject: "Formation SEO avancée"
  predicate: "EXIGE"
  object: "Compétence SEO intermédiaire"

source:
  document_id: "REGLEMENT-FORMATION"
  version: "2.1"
  page: 18
  section: "Prérequis"

extraction:
  method: "manuelle"
  extracted_by: "knowledge-engineer"
  extracted_at: "2026-07-10"

validation:
  status: "validé"
  validated_by: "responsable-pedagogique"
  validated_at: "2026-07-12"

validity:
  effective_from: "2026-01-01"
  effective_until: null

Pourquoi conserver la provenance ?

Vérifier une réponse

L’utilisateur peut consulter le passage original.

Résoudre une contradiction

Deux faits différents peuvent provenir de versions ou de contextes différents.

Mettre à jour les connaissances

Lorsqu’un document change, il est possible d’identifier les connaissances concernées.

Expliquer une décision

Le système peut présenter :

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

Auditer

Une organisation peut reconstruire les éléments utilisés à une date donnée.

Corriger les erreurs

Si une extraction automatique est mauvaise, la source permet de revenir au texte.

Évaluer la confiance

Une règle officielle et une hypothèse issue d’un commentaire ne doivent pas posséder le même statut.

Les différentes catégories de sources

Source primaire

Document ou donnée faisant directement autorité dans le domaine.

Exemples :

contrat signé ;
texte réglementaire ;
procédure validée ;
base métier officielle ;
mesure d’un capteur.

Source secondaire

Contenu interprétant ou résumant une source primaire.

Exemples :

guide ;
synthèse ;
article ;
présentation ;
résumé automatique.

Source humaine

entretien ;
atelier ;
observation ;
déclaration d’expert ;
retour utilisateur.

Source calculée

Résultat produit à partir d’autres données.

Exemple :

Risque élevé

calculé à partir de :

plusieurs indicateurs ;
une règle ;
un modèle.

Source générée

Contenu proposé par un LLM ou un système automatique.

Elle doit être identifiée comme telle.

Hiérarchie des sources

Définissez une hiérarchie selon le domaine.

Exemple :

1. Texte réglementaire en vigueur
2. Contrat applicable
3. Procédure validée
4. Base métier officielle
5. Documentation interne
6. Historique des cas
7. Avis d’expert
8. Proposition automatique

Cette hiérarchie ne doit pas être universelle.

Dans certains domaines, l’expert possède davantage d’autorité qu’un document ancien.

Construire un registre des sources

Le registre des sources constitue le point d’entrée de la gouvernance documentaire.

Champ	Exemple
Identifiant	PROC-X200-4.2
Titre	Procédure de diagnostic X200
Type	Procédure
Auteur	Support réseau
Propriétaire	Responsable support
Version	4.2
Statut	Actif
Date d’application	2026-01-15
Niveau d’accès	Interne
Remplace	PROC-X200-3.1
Prochaine révision	2027-01-15

Identifiant stable

L’identifiant ne doit pas dépendre uniquement du nom du fichier.

Mauvais exemple :

procedure-finale-vraiment-definitive.pdf

Meilleur exemple :

PROC-X200

avec une propriété :

version: 4.2

Document logique et fichiers physiques

Un même document logique peut posséder plusieurs fichiers.

Document logique :
Procédure X200

Versions :
3.1
4.0
4.2

Il est utile de distinguer :

l’identité permanente du document ;
ses versions ;
les fichiers associés.

Les types de versionnement

Version majeure

Modification importante du sens ou du comportement.

Exemple :

3.0 → 4.0

La procédure change profondément.

Version mineure

Ajout ou modification sans rupture complète.

4.1 → 4.2

Correction

Modification éditoriale sans impact métier.

4.2.0 → 4.2.1

Les règles de numérotation doivent être documentées.

Versionner les connaissances extraites

Le document source et la connaissance extraite peuvent évoluer séparément.

Exemple :

Document :

Procédure X200 version 4.2

Connaissance extraite :

Règle diagnostic version 1.3

La règle 1.3 peut intégrer :

un passage du document ;
une validation experte ;
une exception provenant d’une autre source.

Il faut donc versionner les deux niveaux.

Versionner une ontologie

Les modifications possibles comprennent :

nouvelle classe ;
relation renommée ;
contrainte ajoutée ;
propriété supprimée ;
définition modifiée.

Chaque version doit conserver :

le numéro ;
la date ;
les changements ;
la compatibilité ;
le plan de migration.

Versionner un graphe

Un graphe peut évoluer en continu.

Deux approches sont possibles :

Version courante avec historique

Les relations possèdent :

date de début ;
date de fin ;
statut.

Instantanés

Des copies du graphe sont conservées à certaines dates.

Le choix dépend :

du volume ;
du besoin d’audit ;
des performances ;
du niveau de détail attendu.

Les dates essentielles

Date de création

Quand le contenu a-t-il été produit ?

Date de publication

Quand a-t-il été rendu accessible ?

Date de validation

Quand a-t-il été approuvé ?

Date d’application

À partir de quand doit-il être utilisé ?

Date d’expiration

Quand cesse-t-il d’être applicable ?

Date de révision

Quand a-t-il été examiné pour la dernière fois ?

Prochaine révision

Quand doit-il être vérifié à nouveau ?

Exemple

created_at: "2025-12-01"
published_at: "2025-12-20"
validated_at: "2025-12-15"
effective_from: "2026-01-01"
effective_until: null
last_reviewed_at: "2026-06-30"
next_review_at: "2027-01-15"

L’ordre chronologique peut varier selon le processus, mais chaque date doit être définie.

Représenter le remplacement d’une version

Procédure 4.2 → REMPLACE → Procédure 3.1

La version 3.1 doit être :

marquée comme obsolète ;
exclue des réponses actuelles ;
conservée pour l’historique ;
reliée à la nouvelle version.

Métadonnées minimales d’une source

document_id: "PROC-X200"
version: "4.2"
title: "Procédure de diagnostic X200"
document_type: "procedure"
status: "active"
owner: "support-reseau"
effective_from: "2026-01-15"
access_level: "interne"
replaces:
  - document_id: "PROC-X200"
    version: "3.1"

Métadonnées d’un fragment RAG

Un fragment doit hériter des métadonnées du document.

chunk_id: "PROC-X200-4.2-CHUNK-017"
document_id: "PROC-X200"
document_version: "4.2"
section: "Diagnostic du voyant rouge"
page: 12
position: 17
status: "active"
access_level: "interne"

Sans cette liaison, les citations peuvent devenir imprécises.

La provenance dans un système RAG

Le processus doit conserver :

Question
  ↓
Fragments retrouvés
  ↓
Scores
  ↓
Contexte transmis
  ↓
Réponse
  ↓
Citations

Pour chaque réponse, il devrait être possible d’identifier :

les fragments candidats ;
les fragments retenus ;
les versions ;
les filtres ;
le modèle ;
le prompt ;
la réponse finale.

Journal d’une réponse

request_id: "REQ-00458"
question: "Quelle procédure s’applique au X200 ?"

retrieval:
  filters:
    product: "X200"
    status: "active"
  selected_chunks:
    - "PROC-X200-4.2-CHUNK-017"
    - "MANUEL-X200-2.0-CHUNK-044"

generation:
  model: "modele-production"
  prompt_version: "RAG-SUPPORT-3.2"

answer:
  citations:
    - "PROC-X200-4.2"

Les informations sensibles doivent être protégées dans les journaux.

La provenance dans un graphe de connaissances

La provenance peut être représentée au niveau :

du nœud ;
de la relation ;
de l’affirmation ;
du sous-graphe ;
du document.

Relation sourcée

Formation SEO avancée
  → EXIGE
  → Compétence SEO intermédiaire

Provenance :

Source : Règlement pédagogique 2.1
Section : Prérequis
Date d’application : 2026-01-01
Statut : Validé

Plusieurs sources pour un même fait

Source A → soutient → Fait
Source B → soutient → Fait

Le système peut mesurer :

le nombre de sources ;
leur indépendance ;
leur autorité ;
leur fraîcheur.

Une source peut contredire un fait

Source C → contredit → Fait

Il est parfois préférable de conserver les différentes affirmations plutôt que de choisir immédiatement.

Fait et affirmation

Une approche rigoureuse distingue :

Le fait supposé

et :

L’affirmation produite par une source

Exemple :

Source A affirme que le siège est à Toulouse.
Source B affirme que le siège est à Bordeaux.

Le système conserve deux affirmations avant arbitrage.

Les niveaux de confiance

La confiance ne doit pas être réduite à un nombre arbitraire.

Elle peut dépendre de plusieurs dimensions.

Autorité

La source possède-t-elle une valeur officielle ?

Fraîcheur

Est-elle encore actuelle ?

Indépendance

Plusieurs sources se copient-elles entre elles ?

Précision

La source formule-t-elle explicitement la connaissance ?

Validation

Un expert a-t-il vérifié l’extraction ?

Cohérence

La connaissance est-elle compatible avec les autres faits ?

Exemple de fiche

confidence:
  authority: "élevée"
  freshness: "élevée"
  extraction_quality: "élevée"
  human_validation: true
  overall_status: "confirmé"

Cette représentation est souvent plus informative qu’un score unique.

Statuts de confiance

Confirmé
Probable
À vérifier
Contesté
Obsolète
Proposition automatique

Le système doit adapter son langage.

Confirmé

La procédure exige une vérification de la synchronisation.

Probable

Le voyant rouge peut indiquer une perte de synchronisation.

Contesté

Les sources disponibles divergent sur le périmètre d’application.

Proposition automatique

Une relation possible a été détectée, mais elle n’a pas encore été validée.

Gérer les contradictions entre versions

Exemple :

Version 3.1 :

Redémarrer immédiatement.

Version 4.2 :

Vérifier la synchronisation avant le redémarrage.

Le système doit déterminer :

la version active ;
la date d’application ;
les anciens cas concernés ;
les réponses à produire aujourd’hui.

Réponse actuelle

La version 4.2, actuellement active, impose une vérification de la synchronisation avant le redémarrage.

Réponse historique

À la date de l’incident de 2024, la version 3.1 était applicable.

Le contexte temporel modifie la réponse.

Gérer les contradictions entre sources simultanées

Deux sources actives peuvent diverger.

Processus recommandé :

comparer leur périmètre ;
comparer leur autorité ;
vérifier les dates ;
identifier une éventuelle exception ;
demander un arbitrage ;
conserver l’historique.

Exemple

Manuel produit :
Redémarrage autorisé.

Procédure de sécurité :
Redémarrage interdit en présence d’un bruit métallique.

La procédure de sécurité peut être plus spécifique et prioritaire.

La contradiction apparente devient une règle et une exception.

Représenter les transformations

Une connaissance peut passer par plusieurs étapes.

Document original
  ↓ extraction
Fragment nettoyé
  ↓ analyse
Relation proposée
  ↓ validation
Relation publiée
  ↓ résumé
Réponse utilisateur

Chaque transformation doit pouvoir être identifiée.

Exemple

derived_statement:
  id: "STMT-458"

derived_from:
  - "CHUNK-017"

transformation:
  type: "relation-extraction"
  tool: "extractor-v2"
  date: "2026-07-10"

validation:
  reviewer: "expert-support"
  date: "2026-07-12"

Une citation n’est pas une preuve automatique

Une réponse peut citer un document sans que le passage soutienne réellement l’affirmation.

Il faut vérifier :

la correspondance entre l’affirmation et le passage ;
le statut du document ;
la version ;
le contexte ;
l’absence d’exception.

Évaluer les citations

Pour chaque affirmation importante :

Affirmation
  ↓
Citation présente ?
  ↓
Source correcte ?
  ↓
Passage compatible ?
  ↓
Version active ?

Format de citation interne

Exemple :

[Procédure X200 — version 4.2 — section 3.2]

Le lien peut pointer vers :

le document ;
une page ;
une section ;
un fragment.

Construire une politique des sources

La politique doit préciser :

quelles sources sont acceptées ;
lesquelles peuvent produire des règles ;
lesquelles nécessitent une validation ;
comment gérer les versions ;
comment citer ;
comment traiter les contradictions ;
quand réviser ;
comment archiver.

Exemple de politique

1. Toute règle publiée doit posséder une source.
2. Une extraction automatique ne peut pas être publiée sans validation.
3. Les documents obsolètes sont exclus du RAG de production.
4. Les anciennes versions sont conservées pour l’audit.
5. Toute contradiction critique est transmise au propriétaire métier.
6. Les citations doivent inclure le titre, la version et la section.

Automatiser les contrôles

Contrôles possibles :

source absente ;
version vide ;
statut inconnu ;
date d’application manquante ;
contenu expiré ;
référence cassée ;
fragment orphelin ;
relation sans provenance ;
document sans propriétaire.

Rapport de contrôle

Erreur	Nombre
Relations sans source	34
Documents sans version	12
Fragments orphelins	8
Sources expirées actives	4
Connaissances sans validateur	19

Mesurer la couverture de provenance

Couverture globale

Connaissances avec provenance
÷
Connaissances totales

Couverture critique

Règles critiques avec provenance complète
÷
Règles critiques totales

L’objectif devrait être plus élevé pour les connaissances à risque.

Mesurer la fraîcheur

Connaissances révisées dans le délai
÷
Connaissances soumises à révision

Mesurer la qualité des citations

Citations soutenant réellement l’affirmation
÷
Citations vérifiées

Architecture minimale avec Markdown

Un simple fichier Markdown peut conserver une provenance utile.

---
title: "Prérequis de la formation avancée"
knowledge_id: "KNOW-FORM-017"
version: "2.0"
status: "validé"

source:
  title: "Règlement pédagogique"
  version: "2.1"
  section: "Prérequis"
  page: 18

validity:
  effective_from: "2026-01-01"
  effective_until: null

validation:
  validator: "Responsable pédagogique"
  validated_at: "2026-07-12"

review:
  next_review: "2027-01-15"
---

Cette structure est déjà suffisante pour un petit site ou un prototype.

Architecture avancée

Une organisation peut séparer :

référentiel des sources ;
référentiel des connaissances ;
graphe de provenance ;
journal des transformations ;
index RAG ;
système de versions ;
outils d’audit.

Exemple conceptuel

Document
  → contient → Passage
  → soutient → Affirmation
  → validée par → Expert
  → utilisée dans → Règle
  → produit → Décision

Cette structure permet de remonter de la décision au document original.

Checklist des sources

[ ] chaque source possède un identifiant stable ;
[ ] le propriétaire est défini ;
[ ] la version est indiquée ;
[ ] le statut est connu ;
[ ] la date d’application est présente ;
[ ] le niveau d’accès est défini ;
[ ] les remplacements sont documentés ;
[ ] la prochaine révision est planifiée.

Checklist des connaissances

[ ] chaque connaissance importante possède une source ;
[ ] le passage utilisé est identifiable ;
[ ] la méthode d’extraction est connue ;
[ ] le statut de validation est présent ;
[ ] le périmètre est défini ;
[ ] les dates de validité sont conservées ;
[ ] les contradictions sont documentées ;
[ ] les transformations sont traçables.

Checklist RAG

[ ] chaque fragment conserve le document parent ;
[ ] les versions obsolètes sont filtrées ;
[ ] les citations renvoient au bon passage ;
[ ] les droits sont appliqués avant la recherche ;
[ ] le contexte transmis est journalisé selon les règles de sécurité ;
[ ] la version du prompt et du modèle est connue ;
[ ] les réponses importantes peuvent être auditées.

Erreurs fréquentes

Utiliser le nom du fichier comme seule identité

Le nom peut changer ou être dupliqué.

Confondre date de publication et date d’application

Une règle peut être publiée avant son entrée en vigueur.

Écraser les anciennes versions

Les décisions historiques deviennent impossibles à expliquer.

Citer un document sans passage précis

La vérification reste difficile.

Considérer une source secondaire comme primaire

Un résumé peut déformer le contenu original.

Publier une extraction automatique sans statut

L’utilisateur ne sait pas si elle a été vérifiée.

Attribuer un score de confiance arbitraire

La valeur numérique donne une fausse précision.

Conserver la source au niveau du document uniquement

Certaines relations proviennent de sections différentes ou de plusieurs documents.

À retenir

La provenance décrit l’origine et les transformations d’une connaissance.
Une référence précise identifie le passage utilisé.
Les sources primaires et secondaires doivent être distinguées.
Chaque source doit posséder un identifiant stable.
Le document logique doit être distingué de ses versions.
Les connaissances extraites peuvent avoir leur propre version.
Les dates de publication et d’application sont différentes.
Les anciennes versions doivent être archivées, pas simplement écrasées.
Les relations d’un graphe doivent conserver leurs sources.
Les citations doivent réellement soutenir les affirmations.
Les sorties automatiques doivent posséder un statut de validation.
Une bonne provenance permet de vérifier, corriger et auditer les réponses.

Continuer

Mettre en place une gouvernance des connaissances

Construire un système RAG fiable

Extraire les connaissances d’un corpus documentaire