Base de connaissances IA : versionner les changements avant qu’ils ne dégradent les réponses

Une base de connaissances n’est pas une simple réserve de fichiers. Dès qu’un assistant ou un agent s’en sert pour répondre, classer ou guider une action, chaque suppression, ajout, droit d’accès ou changement de découpage peut modifier le résultat. Mettre à jour le corpus sans version ni recette revient à changer une dépendance de production sans savoir quel comportement vient de bouger.

Il ne s’agit pas de figer l’information. Une base utile doit évoluer. Le bon objectif est plus modeste : savoir quelle version a été interrogée, ce qui a changé, quelles questions risquent d’être affectées et comment revenir en arrière si la qualité ou les permissions se dégradent.

Réponse en bref

Pour mettre à jour une base de connaissances utilisée par une IA :

1. identifiez la version actuellement active et son périmètre ;
2. décrivez le changement en termes de documents, droits, champs et règles de découpage ;
3. estimez les réponses ou décisions susceptibles de changer ;
4. préparez un petit jeu de questions de régression lié à cet impact ;
5. indexez une version candidate hors du flux actif ;
6. vérifiez récupération, citations, permissions et réponse finale ;
7. publiez uniquement avec une règle de retour arrière et un responsable identifié.

Votre première action est de produire un inventaire sans contenu sensible : identifiant de document, propriétaire, date, type, niveau d’accès, état actif ou retiré. Sans ce registre, vous ne pouvez ni expliquer une réponse ni retirer proprement une information devenue inadaptée.

Pourquoi le corpus mérite un contrôle de changement

Le NIST définit une configuration de référence comme un ensemble documenté de spécifications, revu à un instant donné, qui ne change que par procédure de contrôle. Cette définition ne vise pas spécialement les bases RAG, mais elle fournit un bon modèle : le corpus, ses règles d’indexation et ses permissions forment ensemble une configuration qui influence le service.

Deux modifications qui semblent anodines peuvent avoir des effets opposés. Ajouter un document récent peut améliorer une réponse, mais aussi faire remonter un brouillon moins fiable. Supprimer une ancienne procédure peut retirer une information obsolète, mais laisser une question sans réponse. Modifier le découpage peut conserver tous les mots tout en séparant une condition de son exception. Une réponse fluide ne révèle pas forcément ce déplacement.

Le guide sur les sorties structurées IA et JSON Schema couvre la validation d’un résultat au format attendu. Ici, le sujet est différent : gouverner le changement du corpus lui-même, avant qu’il n’atteigne les utilisateurs.

Cette séparation fait partie de l’architecture de mémoire d’un agent IA : les connaissances validées ne doivent pas être confondues avec une conversation, un état de tâche ou une préférence personnelle.

Définir l’unité de version

Une version ne doit pas être un horodatage opaque. Elle doit pouvoir être comparée. Donnez-lui un identifiant, une date, un responsable et un état : candidate, active, retirée ou restaurée. Attachez-y au minimum quatre listes :

• les documents ajoutés, modifiés, retirés ou dont l’accès a changé ;
• la méthode d’extraction, de découpage et d’indexation ;
• les règles de filtrage par rôle ou source ;
• le jeu de tests utilisé et son résultat.

Un registre minimal peut ressembler à ceci :

knowledge_version: kb-2026-08-05-02
parent_version: kb-2026-07-28-01
change_type: retrait + remplacement
documents_affected: 14
access_policy_changed: non
retrieval_configuration_changed: oui, taille de segment
test_set: support-facturation-v3
approval: responsable connaissance + propriétaire métier
rollback_target: kb-2026-07-28-01

Ne placez pas dans ce journal le texte complet de documents confidentiels. Des identifiants internes, une catégorie et un résumé non sensible suffisent généralement à reconstruire la décision dans l’espace autorisé.

Faire un diff d’impact avant l’indexation

Le diff ne compare pas seulement le nombre de fichiers. Il pose quatre questions.

Quelle affirmation est touchée ?

Repérez les règles, tarifs, procédures, définitions ou exceptions qui changent. Lorsqu’un document remplace un autre, liez-les explicitement. Un ajout sans relation peut créer deux versions contradictoires de la même consigne.

Qui peut voir ce changement ?

Un changement de permission est aussi important qu’un changement de texte. Vérifiez que les documents d’un rôle ne sont ni récupérés pour un autre rôle, ni masqués à une personne qui doit les consulter. Les filtres appliqués après la recherche méritent une attention particulière : un extrait peut déjà avoir influencé la sélection avant son exclusion.

Quelles questions risquent de changer ?

Listez les formulations réelles ou synthétiques qui couvrent l’affirmation modifiée. Ne cherchez pas à couvrir toutes les questions possibles. Visez les demandes fréquentes, les cas à enjeu et les formulations ambiguës. Une même règle doit être testée à la fois par une question directe et par une question qui appelle son exception.

Quel effet est attendu ?

Décrivez le comportement attendu : nouvelle réponse, refus justifié, citation différente, absence de réponse ou routage vers une personne. Cette étape évite de juger la version candidate à l’intuition après coup.

La recette en quatre niveaux

Niveau 1 : présence et fraîcheur

La version candidate contient-elle les documents prévus, sans doublon manifeste ? Les documents retirés ont-ils réellement disparu de l’index et des caches prévus ? Comparez les identifiants, les dates de mise à jour et le nombre de segments. Un compteur identique ne prouve pas une indexation correcte, mais un écart inattendu doit être expliqué.

Niveau 2 : récupération

Pour chaque question de test, vérifiez quels passages sont sélectionnés. Le bon passage doit être suffisamment précis, autorisé pour le rôle et relié au document attendu. Une réponse exacte obtenue grâce à une connaissance générale du modèle ne valide pas votre base.

Niveau 3 : réponse et attribution

Vérifiez que la réponse ne dépasse pas ce que les passages permettent de dire. Si le produit affiche des références, elles doivent conduire à la bonne source et à la bonne version. Le contrôle des affirmations reste nécessaire : une citation est une piste de vérification, pas une garantie automatique, comme l’explique le protocole pour vérifier une réponse IA.

Niveau 4 : permissions et refus

Testez un rôle autorisé, un rôle non autorisé et une question qui n’a pas de base suffisante. Le comportement attendu peut être une réponse courte, une redirection ou un refus. Une absence de réponse est parfois la meilleure sortie ; elle doit néanmoins être compréhensible pour l’utilisateur.

Un jeu de régression qui reste maintenable

Commencez avec vingt à trente questions, pas avec un millier. Pour chaque test, enregistrez l’intention, le rôle, le résultat attendu, les documents autorisés, le type d’acceptation et l’impact si le test échoue. Revoyez ce jeu quand une question utilisateur révèle une lacune réelle.

Champ	Exemple de valeur
identifiant	KB-REG-014
intention	règle de remboursement applicable
rôle	support interne
attente	réponse avec condition et exception
source attendue	PROC-REM-2026-03
verdict	accepté, à revoir, refus attendu
criticité	élevée

Ne trichez pas avec une réponse modèle imposée mot pour mot. Les formulations peuvent varier ; vérifiez plutôt les faits indispensables, les conditions, les omissions interdites et la bonne orientation en cas d’incertitude.

Déployer par version candidate, pas par écrasement

Indexez la version candidate à côté de la version active si l’architecture le permet. Exécutez la recette avec une configuration stable : même modèle, mêmes filtres et mêmes paramètres, sauf si le changement porte explicitement sur l’un d’eux. Sinon vous ne saurez pas ce qui explique un résultat différent.

Le NIST associe le suivi post-déploiement à la gestion des incidents, à la récupération et au changement. Concrètement, cela signifie qu’une version ne devient active qu’avec un propriétaire, une fenêtre d’observation et une cible de restauration déjà connue. Notez aussi les changements de fournisseur ou de modèle : ils peuvent modifier la récupération même si le corpus est inchangé.

Lorsque l’assistant déclenche une action, faites suivre le changement par une validation humaine et une règle d’idempotence. Une base corrigée ne doit pas pousser l’agent à rejouer un effet passé. Le guide sur la file d’erreurs d’un workflow IA détaille la séparation entre reprise contrôlée et relance aveugle.

Organiser le retour arrière

Un rollback sain n’efface pas l’enquête. Il restaure la dernière version connue, enregistre le motif et garde les preuves de la recette candidate. Préparez cinq éléments : version cible, personne autorisée, signal de déclenchement, effet sur les sessions en cours et message aux utilisateurs si l’impact est visible.

Déclenchez-le notamment lors d’une fuite de permission, d’une réponse erronée à fort impact, d’une baisse nette sur les tests critiques ou d’une indexation incomplète. Une différence mineure de formulation ne mérite pas forcément un retour arrière ; elle mérite peut-être une analyse et un nouveau test. La proportion est une décision métier et de risque, pas une règle universelle.

Distinguer correction urgente et évolution normale

Une correction qui retire une information dangereusement erronée ne suit pas le même calendrier qu’une amélioration de style. Définissez une voie urgente : retrait immédiat, contrôle de la propagation dans les index et caches, vérification ciblée, puis compte rendu. Définissez aussi une voie normale : demande documentée, version candidate, recette et fenêtre d’observation. Les deux voies doivent produire une trace, mais seul le risque justifie de réduire les étapes.

Cette distinction évite deux excès : attendre une réunion mensuelle pour corriger une information critique, ou traiter chaque ajout mineur comme une urgence qui contourne la recette. Elle rend également visible la dette de connaissance : les documents qui reviennent souvent en correction méritent d’être repris à la source, pas seulement réindexés.

Qui décide de la vérité du corpus ?

L’équipe technique peut vérifier l’indexation, mais elle ne peut pas arbitrer seule une règle métier. Attribuez donc chaque famille de documents à un propriétaire de connaissance. Cette personne valide la version de fond ; un responsable d’accès valide les permissions ; le responsable du système confirme le déploiement. Quand ces rôles ne sont pas disponibles, la version doit rester candidate ou répondre de manière plus prudente.

Le registre doit pouvoir signaler l’absence de validation. Ne remplacez jamais une approbation manquante par une date de fichier ou un score de similarité. Une base de connaissances fiable ne consiste pas à tout indexer, mais à maintenir une frontière nette entre information disponible, information retirée et information encore à confirmer.

Limites

Le versionnement ne rend pas un corpus complet, exact ou juridiquement exploitable. Il ne remplace pas une politique de conservation, un contrôle d’accès ni l’expertise métier qui valide les sources. Les tests restent un échantillon : une base peut réussir vingt questions et échouer sur une demande nouvelle. Enfin, les données de test doivent respecter les mêmes règles de confidentialité que le corpus ; utilisez des cas synthétiques lorsque les exemples réels ne sont pas nécessaires.

Articles liés

• Sorties structurées IA et JSON Schema
• Vérifier une réponse IA en cinq minutes
• File d’erreurs d’un workflow IA