Assistant documentaire et RAG sur données métier

Le problème

Le référentiel existe déjà. Il est dans un intranet, une GED, un wiki, des procédures d’exploitation, des tickets, des contrats, des comptes rendus. Le coût n’est pas de le stocker : il est de le retrouver. Un nouvel arrivant met des semaines à savoir où chercher, un support répond deux fois à la même question sans le savoir, une procédure à jour coexiste avec trois versions périmées.

Un modèle de langage seul, sans accès à ces contenus, invente des réponses plausibles. C’est le pire résultat possible : une erreur bien écrite se repère beaucoup moins vite qu’un « je ne sais pas ». Et un outil du marché branché sur vos documents pose vite trois questions auxquelles il répond mal : quel vocabulaire, quels droits d’accès, et où part la donnée. Dans la banque, l’assurance ou le secteur public, cette dernière question décide de tout.

Mon approche

Je construis des systèmes RAG (recherche dans vos documents, puis génération de la réponse à partir des extraits trouvés) avec quatre règles constantes.

• Réponse sourcée. Chaque réponse cite les documents dont elle est tirée. L’utilisateur vérifie en un clic ; la confiance se construit là.
• Droit au silence. Le système répond « l’information n’est pas dans les documents » plutôt que combler le vide. Ce comportement se teste et se mesure.
• Droits d’accès pensés à l’ingestion. Qui a le droit de voir quoi se décide au moment d’indexer, pas après : le filtrage par profil fait partie du cadrage, et il se teste comme le reste.
• Évaluation avant déploiement. On écrit avec le métier un jeu de questions de référence et les réponses attendues. C’est ce jeu qui décide si le système est prêt, et qui permet plus tard de vérifier qu’une modification n’a rien cassé.

Techniquement, je travaille sur une pile open source que je sais faire tourner chez vous : Haystack pour l’orchestration, Qdrant ou pgvector pour l’index, des modèles d’embeddings choisis pour le français et votre domaine (BGE-M3, E5, Solon), un reranking, une recherche hybride qui combine mots-clés et similarité, ragas pour l’évaluation et Langfuse pour tracer chaque requête. Le découpage des documents est pensé pour votre format réel : un contrat, une procédure et un fil de tickets ne se découpent pas de la même façon.

L’auto-hébergement n’est pas un dogme. Quand la donnée peut sortir et que le volume ne justifie pas d’exploiter une inférence en interne, je le dis, et on regarde les fournisseurs acceptables pour votre contexte.

Ce que vous recevez

• Le service RAG déployé dans votre infrastructure, ou sur une infrastructure européenne de votre choix, exposé par une API et, si besoin, une interface web avec votre authentification.
• Le pipeline d’ingestion, rejouable à chaque mise à jour du référentiel, avec ses règles de droits d’accès.
• Le jeu d’évaluation et son rapport : précision mesurée, cas d’échec identifiés, limites connues et assumées.
• Ce qu’il faut pour l’exploiter : supervision, journalisation, procédure de reprise, estimation du coût d’inférence, code versionné et documenté en français.
• Le transfert à l’équipe qui en aura la charge, pour que la maintenance ne dépende pas de moi.

Pour qui

Une DSI ou une direction métier qui dispose d’un référentiel réel, d’un besoin identifié et d’au moins une personne côté métier capable de juger de la qualité des réponses. C’est cette personne qui rend le projet possible : sans expertise métier pour arbitrer, aucune évaluation sérieuse n’est faisable. Une ESN qui cherche ce profil pour une mission chez son client est dans le même cas.

Si les sources ou le périmètre ne sont pas encore arrêtés, commencez par un cadrage : quelques jours de travail peuvent éviter plusieurs semaines de développement inutile.