Une base de connaissances d’entreprise ne se juge pas seulement à la qualité d’une démonstration. Elle doit continuer à répondre correctement lorsque les procédures changent, qu’un collaborateur quitte une équipe ou qu’un document devient confidentiel. Ce travail de maintenance doit être prévu dès le cadrage du projet IA.

Les droits doivent suivre l’information

Se connecter à l’application ne signifie pas avoir accès à tout son contenu. La recherche doit tenir compte des autorisations de la personne qui pose la question. Les extraits transmis au modèle doivent déjà respecter ce périmètre. Une consigne demandant à l’IA de « rester confidentielle » ne remplace pas ce contrôle.

Nous recommandons donc de documenter les groupes, les exceptions et le délai de prise en compte des changements. Un utilisateur retiré d’un projet ne doit pas continuer à en retrouver les documents parce que l’index conserve d’anciens droits. Ce scénario mérite un test explicite.

Supprimer un fichier ne suffit pas toujours

Un document peut avoir produit plusieurs objets : extraits, index de recherche, représentations vectorielles, résumés et réponses mises en cache. Nous proposons de conserver un lien entre chaque contenu dérivé et sa source, puis de définir comment le mettre à jour, le retirer ou le reconstruire.

Une synthèse qui combine plusieurs documents exige une décision supplémentaire : qui peut la lire ? Par défaut, notre recommandation est d’éviter qu’elle élargisse l’accès aux informations utilisées. Si une synthèse destinée à un public plus large est nécessaire, sa validation doit suivre une procédure définie par l’entreprise.

Exemple hypothétique : une procédure de maintenance remplacée

Imaginons un industriel qui remplace une instruction de réglage. La nouvelle version est approuvée, mais un ancien résumé reste disponible dans la base IA. Un technicien pose une question et reçoit une réponse fondée sur ce résumé obsolète.

Le problème dépasse la qualité du modèle. Il faut identifier la version applicable, conserver les références utiles et retirer les contenus dérivés invalidés. Les archives peuvent rester conservées pour leur finalité propre tout en étant exclues des réponses opérationnelles courantes. Cet exemple illustre un risque à tester ; il ne constitue pas un retour d’expérience client Mintera.

Ce qu’il faut décider avant la mise en production

  • Un responsable métier : qui approuve une connaissance et sa date de révision ?
  • Une règle de cycle de vie : que deviennent les versions remplacées, les suppressions et les synthèses dépendantes ?
  • Un fonctionnement en cas d’incertitude : quand demander une validation ou ne pas produire de réponse ?
  • Un budget de maintenance : qui prend en charge les connecteurs, réindexations, contrôles et revues humaines ?

Un accompagnement avec des preuves de fonctionnement

Un projet Mintera Knowledge peut commencer par un périmètre documentaire limité, puis préparer son extension. Le cadrage proposé produit une cartographie des sources et des accès, des règles de publication et de retrait, un jeu de tests métier et une estimation du coût d’exploitation.

Les mesures utiles sont concrètes : réponses appuyées sur la version en vigueur, accès indus observés dans les tests, délai de propagation d’une révocation, temps de correction et coût mensuel de maintien. Elles servent à décider si le système est prêt à être élargi. Une base devient un actif lorsque l’entreprise sait aussi l’entretenir.

Cadrer votre projet de structuration et de gouvernance des connaissances