Base de connaissances IA : vos dossiers interrogeables

Une expertise accumulée, mais difficile à retrouver

Dans beaucoup d'entreprises, l'expérience accumulée sur des années est rangée dans des partages réseau, une gestion électronique de documents (GED), des boîtes mail ou des dossiers clients. Elle existe, mais personne ne sait exactement où. Pour savoir comment une clause a été négociée il y a trois ans, ou comment un dossier semblable a été traité, on interroge le collaborateur le plus ancien. Il devient alors un point de passage obligé.

Le guide publié par n8nlab.io, intitulé « How Law Firms Can Turn Case Files Into a Searchable AI Knowledge Base [Full Guide] », décrit ce problème dans les cabinets d'avocats. Les avocats expérimentés y deviennent les gardiens de la mémoire institutionnelle, et chaque nouveau dossier oblige à reconstruire en partie un savoir que le cabinet possède déjà.

Le constat dépasse largement le monde juridique. Un cabinet d'expertise comptable, un bureau d'études, une agence immobilière ou une PME industrielle avec ses cahiers des charges et ses procédures qualité rencontrent la même difficulté. Les documents sont là, mais ils ne répondent pas aux questions qu'on leur pose.

Chez comm.it, nous traitons ce sujet comme un projet d'architecture globale. Il réunit l'intelligence artificielle, l'automatisation, le réseau et la sécurité.

Le principe : une IA qui répond à partir de vos documents

La technique décrite s'appelle le RAG (Retrieval-Augmented Generation), ou génération augmentée par récupération. Une IA généraliste répond à partir de ses connaissances d'entraînement. Un système RAG procède autrement :

1. il ingère vos documents ;
2. il les découpe en passages cohérents ;
3. il les convertit en représentations mathématiques (embeddings) stockées dans une base de données vectorielle ;
4. lorsqu'un collaborateur pose une question, il retrouve les passages les plus pertinents ;
5. il transmet ces passages à un modèle de langage (LLM), qui rédige une réponse appuyée sur eux et cite ses sources.

L'article de n8nlab.io insiste sur un point : il ne s'agit pas d'un assistant de recherche juridique générique. L'outil rend interrogeables les documents propres à l'organisation. Un outil généraliste résume des connaissances publiques. Une base de connaissances interne ne contient aucun savoir extérieur et montre comment vos équipes ont traité des situations comparables.

Pour une TPE ou une PME, cette distinction est décisive. La valeur vient de votre historique, de vos pratiques et de vos arbitrages passés, pas d'un modèle qui sait un peu de tout.

Le cloisonnement des accès, une décision d'architecture centrale

Pour la source, la décision de conception la plus importante est la suivante : filtrer les droits d'accès avant la recherche par similarité, et non après.

Pourquoi l'ordre des opérations compte

Imaginons une base qui mélange tous les documents de l'entreprise, sans distinction. Un collaborateur pose une question. Le moteur cherche les passages les plus proches dans l'ensemble du fonds, puis retire ceux que l'utilisateur n'a pas le droit de voir. Cette méthode pose deux problèmes :

• Des réponses dégradées : les documents interdits peuvent occuper les premières places des résultats et écarter des documents autorisés pertinents.
• Un risque de fuite : si la logique de filtrage échoue, un contenu restreint peut se retrouver dans le contexte transmis à l'IA, donc dans la réponse.

Dans un cabinet d'avocats, cela reviendrait à franchir une muraille de Chine (ethical wall), c'est-à-dire la séparation imposée entre des dossiers qui ne doivent pas communiquer. Dans une PME, l'enjeu est comparable. Un commercial n'a pas à accéder aux fiches de paie, et un prestataire ne doit pas voir les dossiers d'un autre client.

Comment comm.it met en œuvre ce cloisonnement

Notre approche suit le principe décrit par la source :

• Capturer les droits dès l'ingestion : chaque passage est enregistré avec ses métadonnées, notamment l'identifiant du dossier, l'identifiant du document et la liste des utilisateurs autorisés.
• Appliquer le filtre au niveau de la base de données, avant tout calcul de proximité, et non dans une couche applicative qui pourrait être contournée.
• Synchroniser les droits : la source recommande au minimum une synchronisation quotidienne entre la matrice d'accès centrale et les métadonnées de la base. Un changement de droits dans la GED doit se répercuter dans la base de connaissances.
• Tester le cloisonnement : un utilisateur autorisé sur le dossier A, mais pas sur le dossier B, pose une question précise sur le dossier B. Le résultat attendu est aucun document retrouvé.

Cette dernière étape rejoint notre métier d'intégrateur. Les droits d'accès s'appuient en général sur l'annuaire d'entreprise, l'authentification unique (SSO) et la structure des partages. Nous partons de ce qui existe chez vous au lieu de recréer une gestion des droits parallèle, qui finirait par diverger.

Un découpage adapté à vos documents

La qualité d'un système RAG dépend en grande partie d'une étape discrète : le découpage des documents (chunking). La source rappelle qu'un document juridique ne se découpe pas comme un texte courant. Une coupe à nombre fixe de caractères peut sectionner une clause au milieu d'une phrase et faire perdre à l'IA le contexte dont elle a besoin.

Les paramètres de départ proposés dans le guide sont les suivants :

• des passages d'environ 1 000 tokens, pour conserver assez de contexte autour des clauses complexes ;
• un chevauchement de 200 tokens, pour éviter qu'une définition soit séparée de l'endroit où elle s'applique ;
• des séparateurs logiques (paragraphes, sections, articles), pour couper le texte à ses frontières naturelles.

Le guide indique aussi comment corriger ces réglages. Si la recherche manque des documents manifestement pertinents, les passages sont peut-être trop longs et le passage utile se perd dans du texte standard. La source suggère alors de descendre à 500 tokens en augmentant le chevauchement.

Chez comm.it, nous ne fixons pas ces paramètres une fois pour toutes. Un contrat, un compte rendu de chantier, une procédure qualité et un échange d'e-mails n'ont pas la même structure. Nous analysons vos types de documents, nous définissons des règles de découpage pour chacun, et nous conservons systématiquement les métadonnées de citation : document, section, page. Sans elles, l'IA ne peut pas indiquer d'où vient une information.

Une réponse sourcée, ou pas de réponse

Le second garde-fou concerne la génération de la réponse. La source décrit trois exigences :

• Répondre uniquement à partir des passages fournis, sans recourir aux connaissances générales du modèle.
• Citer chaque affirmation avec une référence précise au document et à la page.
• Refuser explicitement lorsque les documents accessibles ne contiennent pas la réponse, avec une phrase de refus prédéfinie.

Le guide recommande aussi une température à 0 pour supprimer la variation créative du modèle et privilégier l'exactitude.

Les cas limites à anticiper

L'analyse de n8nlab.io présente trois scénarios de test que nous reprenons dans nos recettes :

• Le cas nominal : une question précise, une réponse précise, une citation à vérifier dans le document source.
• La question vague, du type « quelle est notre clause standard ? ». L'IA risque de fabriquer une moyenne qui n'existe pas. La parade consiste à lui demander de lister des exemples précis plutôt que de synthétiser.
• L'échec de recherche : le collaborateur emploie un vocabulaire différent de celui des documents et aucun passage n'est retrouvé. Le comportement attendu est le refus. Si l'IA invente une réponse, il faut renforcer les consignes ou revoir la température.

L'humain reste dans la boucle

La source est claire : un tel système ne doit jamais produire seul un conseil engageant envoyé directement à un client. C'est un outil de recherche interne. La validation humaine intervient à la fin du processus, quand le professionnel vérifie la source citée avant de s'en servir. Nous concevons nos automatisations avec ce principe : l'IA accélère la recherche, la décision reste à vos équipes.

Héberger l'outil dans un environnement maîtrisé

Ces données sont confidentielles. Le guide pose donc des prérequis d'infrastructure stricts :

• un orchestrateur auto-hébergé, pour que les flux de données ne transitent pas par des serveurs SaaS publics ;
• une base vectorielle sous votre contrôle direct ;
• un accès à la GED via un compte de service en lecture seule ;
• un accès au modèle de langage avec, si l'offre le permet, un engagement de non-conservation des données ;
• une matrice d'accès documentée reliant chaque utilisateur aux dossiers autorisés.

Selon la FAQ de l'article, ce type de projet est sûr à condition que l'infrastructure soit hébergée en interne ou dans un cloud privé dédié, ce qui garantit la souveraineté des données.

Le réseau et l'hébergement sont au cœur du métier de comm.it. Nous pouvons prendre en charge :

• le déploiement sur vos serveurs ou dans un environnement privé dédié ;
• l'accès à l'outil derrière un VPN avec authentification SSO, comme le recommande la check-list de la source ;
• la segmentation réseau, pour isoler les composants de la base de connaissances du reste du système d'information ;
• la gestion des secrets et des identifiants : le jeton d'accès à la GED ne doit avoir que des droits de lecture, jamais d'écriture ni de suppression.

La mise en production : traçabilité, coûts et fiabilité

Un prototype qui fonctionne en démonstration ne suffit pas pour un usage quotidien. La check-list de production proposée par n8nlab.io correspond à nos propres exigences :

• Journalisation : chaque requête est enregistrée avec l'identifiant de l'utilisateur et les documents retrouvés. Vous disposez ainsi d'une piste d'audit si un problème d'accès est signalé.
• Limitation du débit : un plafond de requêtes par utilisateur évite qu'un script mal configuré épuise le budget d'API du modèle de langage.
• Jeu d'évaluation : la source propose une trentaine de questions de référence associées à leurs bons documents sources, à rejouer après chaque mise à jour du modèle pour vérifier que la recherche et les citations restent justes.
• Robustesse de l'ingestion : les API de GED appliquent souvent des limites de débit lors de l'import initial. Il faut prévoir des tentatives automatiques avec délai croissant, un traitement par lots et des pauses volontaires.

Préparer la croissance

Le guide mentionne aussi plusieurs optimisations lorsque le volume augmente. Au-delà d'une centaine de milliers de passages, il recommande des index de recherche approximative plutôt qu'une recherche exhaustive. Il propose aussi une couche de cache : si une question identique a été posée récemment par un utilisateur ayant exactement les mêmes droits, la réponse en cache est renvoyée sans solliciter à nouveau le modèle.

La condition « mêmes droits » est essentielle. Un cache mal conçu peut contourner le cloisonnement. Nous l'intégrons dès la conception.

Une démarche progressive, adaptée à une PME

La source estime qu'une preuve de concept sur un ensemble limité de dossiers non confidentiels représente une vingtaine d'heures d'ingénierie. Une mise en production qui ingère des milliers de fichiers et respecte les cloisonnements de la GED demande en revanche plusieurs semaines.

Nous appliquons donc une démarche en étapes :

1. Audit

Nous vérifions ce que permet votre GED ou votre stockage documentaire, en particulier la possibilité d'exporter les listes de contrôle d'accès de façon systématique. Si les droits ne peuvent pas être récupérés, le projet doit d'abord passer par une remise à plat des partages.

2. Pilote

La source suggère de commencer avec une cinquantaine de dossiers clos et peu sensibles. Ce périmètre restreint permet de régler le découpage et la recherche sans risque.

3. Infrastructure

Nous définissons l'hébergement de la base vectorielle et de l'orchestrateur, le mode d'accès (VPN, SSO) et la supervision.

4. Industrialisation

Nous élargissons le périmètre, mettons en place la synchronisation des droits, la journalisation et l'évaluation continue, puis formons les utilisateurs.

5. Intégration aux outils du quotidien

La source évoque une interrogation depuis un portail interne ou une messagerie d'équipe. Nous pouvons aussi relier la base de connaissances à votre CRM ou à votre ERP, pour qu'un collaborateur interroge l'historique d'un client directement depuis sa fiche, avec ses propres droits d'accès.

Au-delà du juridique

Le guide porte sur les cabinets d'avocats, mais ses principes s'appliquent à d'autres activités :

• Cabinets de conseil et d'expertise : retrouver comment une problématique a été traitée pour un client comparable.
• Services techniques et bureaux d'études : interroger des années de rapports, de notices et de comptes rendus d'intervention.
• Services RH et administratifs : répondre aux questions internes à partir des procédures en vigueur, avec citation du document de référence.
• Équipes commerciales : retrouver les conditions négociées dans des contrats passés, dans la limite de leurs droits.

Dans chaque cas, les mêmes règles s'appliquent : droits filtrés avant la recherche, découpage adapté aux documents, réponses sourcées ou refus explicite, hébergement maîtrisé et validation humaine en fin de processus.

En résumé

Une base de connaissances IA bien conçue ne remplace pas l'expertise de vos équipes. Elle la rend accessible plus rapidement. Le projet repose sur un ensemble cohérent : l'automatisation de l'ingestion, la sécurité réseau, la gestion des identités, l'hébergement et l'intégration aux outils métier. Ce sont les domaines dans lesquels comm.it accompagne les TPE et PME.

Source : « How Law Firms Can Turn Case Files Into a Searchable AI Knowledge Base [Full Guide] », publié par n8nlab.io.

Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

Source : How Law Firms Can Turn Case Files Into a Searchable AI Knowledge Base Full Guide