Chatbot entreprise : organiser les connaissances et les droits

Un chatbot entreprise qui répond à la question « quel est notre tarif de renouvellement ? » avec la mauvaise version du document n'est pas un problème d'intelligence artificielle : c'est un problème d'organisation des connaissances et des droits. La recherche sémantique trouve du texte pertinent, elle ne décide pas qui a le droit de le lire. Cet article décrit comment structurer une base documentaire multiéquipes, où placer le filtrage des permissions, comment gérer les versions et la validité, et quels tests mener avant l'ouverture à vos équipes.

Pourquoi la recherche ne suffit pas à autoriser

Un moteur de recherche, sémantique ou non, répond à une question de pertinence : ce paragraphe ressemble-t-il à la requête ? L'autorisation répond à une question différente : cet utilisateur a-t-il le droit de voir ce contenu ? Les deux opérations doivent rester séparées, car une réponse peut être parfaitement pertinente et strictement interdite à la personne qui la demande.

Le risque le plus courant arrive quand le chatbot construit un index unique de tous les documents, puis filtre « après coup » dans la réponse générée. Si le modèle a déjà reçu le contenu interdit dans son contexte, le filtrage du texte final est cosmétique : des détails peuvent fuiter, reformulés autrement. Le filtrage doit donc se produire avant l'envoi du contexte au modèle, côté serveur, sur la liste des documents autorisés pour l'utilisateur identifié.

Cela a une conséquence de conception : votre chatbot doit connaître l'identité de l'utilisateur au moment de la question, pas seulement à la connexion. Une session anonyme ou un identifiant générique d'équipe rend le filtrage impossible. Si vous reliez le chatbot à d'autres outils avec leurs propres permissions, notre guide sur connecter ses outils : API, MCP et autorisations détaille pourquoi le protocole de transport ne choisit pas les règles métier à votre place.

Trois niveaux de diffusion : public, interne, individuel

Avant d'écrire une ligne d'index, classez vos contenus en trois niveaux de diffusion distincts du niveau de sensibilité perçu.

• Public : contenus que vous pouvez montrer à l'extérieur, par exemple une politique de retours publiée sur votre site ou un guide produit destiné aux clients.
• Interne : contenus partagés à l'échelle de l'entreprise ou d'une équipe, comme une procédure de recrutement ou un tableau de marges par gamme de produits.
• Individuel : contenus attachés à une personne, comme ses notes de frais, ses entretiens ou ses brouillons de contrat.

La difficulté réelle se situe aux frontières. Un compte rendu de négociation avec un client est interne pour la direction commerciale, mais son contenu peut être individuellement identifiable pour les participants. Un document « interne » qui cite un salarié par nom change de nature dès qu'un assistant peut le restituer à quelqu'un d'autre. Le classement doit donc être fait document par document, pas par dossier, et revu quand un document change de contenu.

Le cas fictif : RH, commerce et clients

Prenons un exemple explicitement fictif. Une PME de 80 personnes déploie un chatbot sur sa base documentaire. Trois populations l'utilisent : les RH, l'équipe commerciale et les clients finaux via un portail.

Les RH consultent les grilles salariales internes et les procédures disciplinaires. Les commerciaux consultent les grilles de remise et les fiches produits, mais pas les salaires. Les clients consultent les conditions générales et les fiches produits publiées, mais ni les remises négociées ni quoi que ce soit d'interne.

Sans filtrage côté serveur, une question anodine d'un client — « proposez-vous des remises pour les gros volumes ? » — peut faire remonter un extrait de la grille de remise interne, avec des pourcentages qui n'auraient jamais dû être visibles. La réponse est factuellement juste et commercialement désastreuse. Ce scénario est hypothétique, mais chaque élément en est plausible : la fuite ne vient pas d'une faille exotique, elle vient d'un index unique sans frontière de permission au moment de la recherche.

Filtrage côté serveur : le principe et sa mise en œuvre

Le principe est simple à énoncer : la requête de recherche ne porte que sur le sous-ensemble de documents autorisés pour l'utilisateur courant. Concrètement, chaque document porte des métadonnées de diffusion (niveau, équipe propriétaire, liste d'exceptions), et chaque requête utilisateur est accompagnée de l'identité résolue de l'utilisateur. Le serveur compose ces deux informations pour construire la liste blanche avant toute recherche vectorielle ou par mots-clés.

Trois règles de conception réduisent les erreurs :

1. Défaut fermé : un document sans métadonnées de diffusion n'est indexé nulle part, ou seulement dans un bac à révision. L'oubli d'étiquetage ne doit jamais signifier diffusion large.
2. Héritage contrôlé : si un document hérite les droits de son dossier, tout déplacement de fichier doit déclencher une revue, car l'héritage silencieux est une source classique de divergence entre ce que croit l'équipe et ce que voit l'index.
3. Journal des accès : conserver qui a demandé quoi, et quels documents ont alimenté la réponse, permet d'auditer une fuite ou de corriger un classement. Notre checklist sur les permissions d'un agent IA propose une structure de contrôle à adapter.

Un point souvent négligé : le filtre doit s'appliquer aussi aux résumés, aux titres et aux extraits affichés dans l'interface, pas seulement au texte généré. Un titre de document peut à lui seul révéler une information sensible.

Versions et validité : quand deux sources se contredisent

Une base documentaire vivante contient presque toujours plusieurs documents qui se contredisent : une politique de télétravail de 2023 et sa révision de 2025, deux fiches produits dont une jamais retirée, une note interne contredisant un courriel de direction. Un chatbot qui ne gère pas la validité répondra avec la source la plus « proche sémantiquement » de la question, pas avec la plus à jour.

La gestion des versions demande trois métadonnées minimales : une date d'entrée en vigueur, une date d'expiration ou de retrait, et un lien vers le document qu'il remplace. Au moment de la recherche, les documents expirés sont exclus du contexte — ou, si vous préférez les garder consultables, explicitement signalés comme dépassés dans la réponse.

Exemple de conduite à tenir face à une contradiction détectée : le chatbot reçoit deux sources de niveaux de diffusion identiques, l'une datée de mars 2025, l'autre de janvier 2026, qui donnent des règles de remise différentes. La réponse ne doit pas trancher silencieusement. Elle doit citer les deux sources avec leurs dates, indiquer laquelle est la plus récente et dont elle retient le contenu, et proposer de vérifier auprès du propriétaire du document. Ce comportement se spécifie à la conception ; il n'apparaîtra pas spontanément.

Le même raisonnement vaut pour les extraits de documents structurés. Notre article sur l'automatisation des documents : extraction, preuves et contrôle montre comment conserver la trace du document source pour chaque donnée restituée — une pratique qui devient indispensable quand plusieurs versions coexistent.

Tableau décisionnel : où classer un document

Situation	Niveau de diffusion proposé	Condition d'entrée dans l'index
Politique publiée sur le site	Public	Relecture marketing et juridique faite
Fiche produit destinée aux clients	Public	Version validée, anciennes versions retirées
Procédure d'une équipe (ex. onboarding RH)	Interne, équipe propriétaire	Étiquette d'équipe obligatoire
Grille de remise commerciale	Interne, équipe commerciale	Exclusion explicite des autres équipes
Données individuelles (frais, entretiens)	Individuel	Filtrage par identifiant utilisateur strict
Document sans étiquette claire	Aucun	Hors index jusqu'à classification
Note contenant des noms de personnes	Interne ou individuel	Revue avant indexation
Ancienne version remplacée	Hors index	Conservée en archive, jamais restituée

Ce tableau est un cadre de décision, pas une obligation : adaptez les niveaux à votre organisation, mais gardez la règle du défaut fermé.

Procédure : ouvrir un nouveau corpus au chatbot

Voici une procédure exploitable pour ajouter une équipe à la base documentaire, étape par étape.

1. Inventorier : lister les dossiers de l'équipe, avec volumes approximatifs et propriétaires nommés. Un document sans propriétaire est un document sans décision de diffusion.
2. Classifier : attribuer à chaque document un niveau (public, interne, individuel) et, pour l'interne, l'équipe ou la liste d'exceptions. Traiter les doublons : deux copies de la même note avec des droits différents créent une incohérence garantie.
3. Dater : vérifier les dates d'entrée en vigueur, marquer les documents remplacés, retirer de l'index tout ce qui est expiré.
4. Indexer avec défaut fermé : indexer uniquement les documents étiquetés, en enregistrant les métadonnées de diffusion avec chaque fragment indexé.
5. Tester les accès : exécuter les tests de la section suivante, en particulier les tests croisés entre équipes.
6. Journaliser et revoir : activer le journal des accès, puis planifier une revue trimestrielle du classement avec le propriétaire de l'équipe.

La quatrième étape mérite une attention particulière : si votre outil d'indexation ne permet pas d'attacher des métadonnées de permission à chaque fragment, il faudra soit changer d'outil, soit indexer par cloisons séparées. Un fragment sans métadonnée est un fragment qui fuira tôt ou tard.

Tests d'accès : horizontal et croisement entre clients

Les tests de contenu vérifient que le chatbot répond bien. Les tests d'accès vérifient qu'il ne répond pas trop. Ils sont distincts et le second est plus important.

Test horizontal : pour chaque paire de populations (RH/commercial, commercial/client, RH/client), poser la même question sensible depuis chaque profil et comparer. Par exemple : « Quelle est la grille de remise maximale ? » doit obtenir une réponse documentée pour un commercial, un refus argumenté pour un client, et probablement un refus pour les RH si le document est cloisonné par équipe. Le refus doit être explicite (« ce contenu n'est pas accessible avec votre profil »), pas une réponse vague qui laisse deviner l'existence du document.

Test de croisement entre clients, si vous opérez un chatbot multi-clients : chaque client ne doit jamais voir la trace d'un autre. Cela couvre non seulement les documents, mais les noms, les références de dossiers et les formulations propres à un compte. Le moyen le plus sûr reste la séparation physique des index par client ; la séparation logique par métadonnées exige des tests systématiques, car une seule requête mal filtrée suffit. Notre grille sur l'évaluation des réponses d'un chatbot IA peut servir de support pour formaliser ces scénarios de test avec les équipes métier.

Ajoutez un test de suppression d'accès : retirez un droit à un utilisateur de test, puis vérifiez que ses anciennes questions ne retournent plus le contenu. Si le chatbot met en cache des réponses par session ou par équipe, la révocation doit invalider ce cache — sinon l'utilisateur conserve un accès fantôme après la suppression.

Les limites à assumer

Trois limites méritent d'être dites clairement.

D'abord, le filtrage côté serveur repose sur la qualité du classement initial. Un document mal étiqueté est un document mal filtré. Aucune technique ne compense un classement absent, et la revue humaine initiale reste un travail réel, à budgéter.

Ensuite, la reformulation par le modèle peut contourner des frontières trop fines. Si deux fragments autorisés, mis côte à côte, permettent de reconstituer une information que chacun isolément n'aurait pas révélée, votre filtrage par fragment montre sa limite. Les documents réellement sensibles doivent être cloisonnés au niveau du document entier, voire hors du chatbot.

Enfin, les permissions évoluent. Une personne change d'équipe, un document change de niveau, un client résilie. Le système doit prévoir la révocation comme un cas normal, avec des tests de non-régression, et non comme un correctif exceptionnel. Pour les données personnelles, les grands principes de protection des données décrits par la CNIL — minimisation, durées de conservation, sécurité — donnent un cadre utile pour décider ce qui a vocation à entrer dans l'index du tout.

Erreurs fréquentes et conduite à tenir

La première erreur est de croire qu'un libellé ou un nom de dossier suffit comme frontière. Un dossier nommé « interne » n'empêche rien si l'index ne lit pas cette information. La frontière de permission doit être une donnée structurée que le serveur applique, pas une convention implicite.

La deuxième erreur est de tester uniquement avec des comptes de démonstration qui ont tous les droits. Ces comptes ne révèlent jamais les fuites. Constituez dès le départ des profils de test à droits réduits, un par niveau de diffusion, et rejouez les tests à chaque changement de corpus.

La troisième erreur est de traiter la contradiction de sources comme un bug à faire taire. Deux documents datés qui se contredisent sont un signal de gouvernance documentaire : la bonne conduite est de remonter l'information au propriétaire du contenu, pas de laisser le chatbot choisir arbitrairement la source la plus récente sans le dire.

Enfin, ne confondez pas l'assistant IA entreprise avec un espace de stockage. Si les utilisateurs commencent à y déposer des documents « pour que le chatbot les retrouve », vous perdez le contrôle du classement. Prévoyez un circuit d'entrée unique, avec classification obligatoire, même s'il est plus lent que le dépôt direct.

Si vous souhaitez structurer la base documentaire et les droits d'un chatbot entreprise pour votre organisation, vous pouvez définir une mission avec Edeverse.

Questions fréquentes

Peut-on filtrer les permissions dans le prompt plutôt que côté serveur ?

Non, pas de manière fiable. Le prompt est une instruction que le modèle peut ignorer ou contourner, surtout si le contexte contient déjà le texte interdit. Le filtrage doit se produire avant, sur la liste des documents envoyés au modèle, dans le code serveur.

Comment gérer un document accessible à plusieurs équipes avec des exceptions ?

Attribuez un niveau de base (par exemple interne, équipes A et B) puis une liste d'exceptions nommées, enregistrée comme métadonnée structurée. Le serveur applique d'abord le niveau, puis retire les exceptions. Testez explicitement chaque exception avec un compte dédié.

Que faire quand deux documents à jour se contredisent ?

C'est un problème de gouvernance, pas de technique. La réponse du chatbot doit citer les deux sources avec leurs dates et signaler l'ambiguïté, et le propriétaire du contenu doit trancher. Une contradiction persistante signale souvent un processus de validation documentaire à revoir.

Faut-il un index séparé par client dans un chatbot multi-clients ?

C'est le choix le plus sûr, car il rend la fuite croisée structurellement impossible. La séparation logique par métadonnées est acceptable si elle est accompagnée de tests croisés systématiques et d'un journal des accès, mais elle repose entièrement sur la justesse du filtre.

Comment vérifier qu'une suppression d'accès est effective ?

Retirez le droit à un compte de test, puis rejouez les questions qui retournaient auparavant le contenu concerné, y compris dans une session déjà ouverte. Si des réponses en cache persistent, la révocation doit invalider explicitement ce cache. Ce test fait partie des contrôles à rejouer à chaque évolution du corpus.