Brancher un LLM sur les documents internes d’une entreprise, c’est la demande que je reçois le plus souvent en ce moment. La technique porte un nom un peu barbare, le RAG (Retrieval-Augmented Generation) : avant de répondre, le modèle va chercher les passages pertinents dans vos documents, puis il rédige sa réponse à partir de ce qu’il a trouvé.
La première démo est toujours bluffante. On pose une question sur la procédure des notes de frais, et la réponse tombe en trois secondes, avec le bon paragraphe du bon PDF. C’est à ce moment-là qu’il faut se poser la question que la démo ne pose jamais : qu’est-ce que ce système peut voir, et pour qui ?
Ce que les tutoriels ne montrent pas
Les vidéos « construisez votre ChatGPT sur vos documents en dix minutes » se ressemblent toutes. Une clé d’API OpenAI, une base vectorielle hébergée comme Pinecone, un orchestrateur dans le cloud, et ça fonctionne. C’est une très bonne façon d’apprendre, et pour un prototype personnel je n’ai rien à y redire.
Ces outils font bien leur travail. Ce que la version rapide laisse de côté devient pourtant central dès qu’il s’agit des données d’une entreprise : qui a le droit de lire quoi, qui a posé quelle question, et dans quel pays partent les documents au moment où on les découpe pour les indexer.
Un cas que j’ai croisé
Une entreprise avait branché un assistant interne sur son SharePoint. L’assistant répondait bien, les équipes l’utilisaient et tout le monde était content. Personne n’avait vérifié ce qui avait été indexé.
En posant les bonnes questions, n’importe quel salarié pouvait obtenir la rémunération des membres de la direction, les grandes lignes d’un plan de restructuration qui n’avait pas encore été annoncé et le contenu de contrats clients. Personne ne l’avait voulu. Les documents étaient là depuis des années, dans des dossiers aux droits mal réglés, et l’indexation les avait rendus accessibles d’une seule question.
D’où vient le problème
Un modèle de langage ne sait pas ce qui est confidentiel. Il travaille sur ce qu’on lui donne, et la base vectorielle ne connaît pas davantage les droits de vos utilisateurs. C’est à l’architecture de les faire respecter : savoir qui pose la question, ne chercher que dans les documents qu’il a le droit d’ouvrir, et garder une trace de ce qui a été demandé et de ce qui a été répondu.
Ce filtrage doit se faire au moment où l’on cherche les passages. Demander au modèle de ne pas divulguer une information qu’on lui a déjà fournie ne protège rien, puisqu’une question un peu habile suffit à la faire sortir.
Dans la plupart des entreprises, les droits documentaires sont d’ailleurs flous bien avant tout projet d’IA. Un dossier partagé « temporairement » avec tout le service en 2019, un export de la paie déposé au mauvais endroit : tant qu’il fallait fouiller pour tomber dessus, personne ne le voyait. Un assistant qui répond en trois secondes à n’importe quelle question rend ces documents visibles du jour au lendemain. La faille existait avant le projet, et c’est l’assistant qui l’a mise sous les yeux de tout le monde.
Garder les données chez soi
Pour limiter les transferts hors de l’Union européenne, on peut faire tourner toute la chaîne sur ses propres serveurs : Ollama pour le modèle et les embeddings, PostgreSQL avec pgvector pour la base vectorielle, et un orchestrateur auto-hébergé comme n8n pour relier le tout. Les documents ne quittent alors jamais votre infrastructure.
Cette architecture réduit une partie des risques, mais elle ne règle pas à elle seule la question du RGPD. Il reste la base légale du traitement, l’information des personnes dont les données figurent dans les documents, la durée de conservation et, selon les cas, une analyse d’impact. L’hébergement local en est une pièce parmi d’autres.
La question à se poser avant de choisir un modèle
Avant de comparer les modèles, je demande toujours à mes clients s’ils savent ce que contiennent leurs partages et qui peut y accéder. Un RAG amplifie la gouvernance documentaire que vous avez déjà : si elle est solide, il la rend utile à tout le monde, et si elle est fragile, il met ses failles à la portée de chaque salarié.
Le premier chantier est donc un inventaire : ce qui sera indexé, qui pourra le retrouver, et où partiront les données. C’est une étape moins spectaculaire que la démo, et c’est elle qui permet de passer en production sans mauvaise surprise.
Si vous préparez un projet de ce type, un échange de quinze minutes suffit en général pour repérer les angles morts de votre cas.
Et chez vous ?
Un projet IA en tête, ou une question sur cet article ?
Je vous propose d’en parler lors d’un premier échange. Il me permettra de comprendre votre contexte et d’être plus pertinent dans ma réponse.