RAG en entreprise : passer du POC à un assistant fiable, sécurisé et mesurable

Un prototype de RAG peut être assemblé rapidement : quelques documents, un index vectoriel, un modèle de langage et une interface de conversation. Les premières démonstrations impressionnent lorsque le système retrouve une information précise. Elles disent peu sur son comportement face aux documents contradictoires, aux droits, aux mises à jour, aux questions ambiguës et aux milliers d’utilisateurs.

Passer en production consiste à transformer cette chaîne en service gouverné. Le système doit savoir quelles sources il utilise, expliquer ses réponses, mesurer ses erreurs, protéger les données et fonctionner même lorsque l’un de ses composants ralentit.

Définir la promesse et les limites

Un assistant documentaire ne doit pas être décrit comme capable de « répondre à tout ». La promesse doit préciser :

• corpus couverts ;
• populations autorisées ;
• types de questions ;
• niveau de fraîcheur ;
• langue ;
• décisions qui restent humaines ;
• comportement hors périmètre ;
• preuves attendues.

Une promesse limitée, telle que retrouver et synthétiser les procédures internes avec citations, est plus testable qu’un assistant expert généraliste.

Construire un inventaire de sources

Chaque source possède un propriétaire, un niveau de sensibilité, une date, une version, une langue et une règle de conservation. Les documents obsolètes, brouillons ou dupliqués doivent être identifiés avant indexation.

Le système doit conserver la provenance jusqu’au passage utilisé : identifiant du document, version, section, droits et horodatage. Sans cette traçabilité, une citation visuelle ne garantit pas que la réponse repose sur la bonne source.

Concevoir l’ingestion comme un pipeline de données

L’ingestion ne se limite pas à extraire du texte. Elle doit :

1. récupérer le contenu de façon authentifiée ;
2. détecter le format et les erreurs ;
3. extraire structure, tableaux et métadonnées ;
4. normaliser sans effacer le sens ;
5. découper ;
6. enrichir ;
7. indexer ;
8. valider ;
9. gérer mise à jour et suppression.

Chaque étape est idempotente et observable. Une erreur sur un fichier ne bloque pas tout le lot, mais elle est visible et attribuée.

Le découpage influence la réponse

Un fragment trop court perd les définitions et exceptions. Un fragment trop long dilue les termes utiles et consomme le contexte. Le découpage doit suivre la structure : titres, paragraphes, articles, procédures, tableaux et annexes.

Les métadonnées du parent sont conservées. Pour certaines questions, un passage récupéré doit être enrichi par son titre, sa section ou les paragraphes voisins. Plusieurs stratégies peuvent coexister selon le type de document.

Combiner les méthodes de recherche

La recherche vectorielle retrouve les formulations proches. Le plein texte reste supérieur pour des références, noms, acronymes et citations exactes. Les filtres structurés appliquent langue, date, type, entité et droits.

Une chaîne robuste peut combiner :

• candidats lexicaux ;
• candidats vectoriels ;
• fusion des rangs ;
• reranking ;
• diversification ;
• seuil de pertinence ;
• récupération du contexte voisin.

La sophistication n’a de valeur que si elle améliore un jeu de questions réel.

Les droits doivent intervenir avant la génération

Un utilisateur ne doit pas apprendre l’existence d’un document interdit par un extrait, une citation ou une réponse. Les permissions doivent être reproduites dans l’index ou appliquées pendant la récupération, avec une stratégie fiable de mise à jour.

Un filtrage après récupération peut échouer lorsque les premiers résultats sont interdits. Le moteur doit chercher suffisamment de candidats autorisés. Les caches sont segmentés par politique, pas seulement par texte de requête.

Construire un jeu d’évaluation avant d’optimiser

Un jeu utile contient des questions fréquentes, rares, ambiguës, hors périmètre, contradictoires et sensibles. Pour chaque cas, on conserve les sources de référence et les éléments qu’une bonne réponse doit inclure.

Il faut évaluer séparément :

• récupération : les bons passages ont-ils été trouvés ?
• génération : la réponse respecte-t-elle les passages ?
• citation : les références soutiennent-elles réellement l’affirmation ?
• utilité : la réponse aide-t-elle à accomplir la tâche ?
• refus : le système sait-il ne pas répondre ?

Concevoir une réponse fondée sur les preuves

Le prompt de génération doit rappeler le périmètre, imposer l’usage du contexte et demander un refus lorsque les éléments manquent. Il doit distinguer citation, raisonnement et suggestion.

Une réponse peut indiquer :

• synthèse ;
• sources utilisées ;
• date ou version ;
• points incertains ;
• action suivante ;
• limite du système.

Les citations doivent renvoyer au passage consultable par l’utilisateur, sous réserve de ses droits. Un lien vers un document de cent pages sans localisation n’est pas suffisant.

Traiter les sources contradictoires

Deux procédures peuvent se contredire parce qu’une version est ancienne, qu’elles concernent des périmètres différents ou qu’une erreur existe. Le RAG ne doit pas arbitrer silencieusement.

La stratégie peut favoriser la version en vigueur, signaler la divergence, citer les deux sources et inviter à une validation. Les règles de priorité sont documentées et testées.

Savoir refuser

Le système refuse lorsque le corpus ne contient pas de preuve suffisante, que la question est interdite, qu’elle demande une décision hors responsabilité ou que les droits ne permettent pas de répondre.

Un refus utile explique la limite et propose une voie sûre : reformuler, choisir un périmètre, consulter une source ou contacter un responsable. Il n’invente pas une réponse générique pour remplir le vide.

Protéger contre les instructions contenues dans les documents

Un document peut contenir une phrase demandant au modèle d’ignorer les règles ou d’exfiltrer des informations. Le contenu récupéré doit être traité comme donnée non fiable, jamais comme instruction système.

Les outils et actions sont séparés du RAG documentaire. Les formats sont nettoyés, les liens et scripts neutralisés, et les comportements anormaux testés. Les documents publics et internes peuvent être isolés dans des index ou politiques distincts.

Choisir le modèle par rôle

Le même modèle n’est pas nécessaire pour embeddings, reranking et génération. Le choix dépend de la langue, du domaine, de la latence, du coût et des contraintes de déploiement.

Une architecture peut router les questions simples vers un modèle plus léger et les synthèses complexes vers un modèle plus capable. Le changement de modèle exige une campagne de régression, car les réponses et refus peuvent évoluer.

Gérer le contexte et le coût

Ajouter davantage de passages n’améliore pas toujours la réponse. Le contexte doit être pertinent, dédupliqué, ordonné et limité. Les longs documents peuvent être traités par étapes ou résumés avec traçabilité.

Le coût se suit par requête et par tâche réussie : embedding, recherche, reranking, tokens, stockage et calcul. Un cache peut réutiliser des résultats stables à condition de respecter droits et fraîcheur.

Observabilité

Chaque requête génère un identifiant de corrélation. Les journaux peuvent contenir intention, documents récupérés, scores, version des prompts et modèles, latence, erreurs et feedback, avec une politique stricte de minimisation.

Les tableaux de bord suivent :

• taux de succès ;
• requêtes sans preuve ;
• citations ouvertes ;
• refus ;
• latence ;
• coût ;
• erreurs d’ingestion ;
• retard de mise à jour ;
• cas critiques issus des retours.

Retour utilisateur et validation humaine

Un bouton utile ne se limite pas à pouce haut ou bas. Il permet d’indiquer source incorrecte, réponse incomplète, information périmée ou problème d’accès. Les retours alimentent une file de triage et le jeu d’évaluation.

Pour des usages à risque, la réponse est un brouillon. Une personne valide, modifie et assume la décision. Le système conserve la distinction entre suggestion et action approuvée.

Déployer progressivement

Un pilote doit couvrir une population et un corpus limités, avec un support identifié. Les critères de passage à l’échelle sont définis : qualité, sécurité, coût, adoption, taux d’escalade et capacité d’exploitation.

Le lancement public vient après les tests d’autorisation, de charge, de prompt injection, de suppression de documents et de reprise d’index.

Gouverner le cycle de vie

Les sources changent, les modèles évoluent et les usages se déplacent. Chaque modification de pipeline, modèle, prompt ou politique reçoit une version et une évaluation. Les index peuvent être reconstruits et l’ancienne version conservée le temps d’un retour.

Un comité de produit arbitre les nouveaux corpus, le niveau de risque et les demandes d’action. Le RAG devient ainsi une capacité maîtrisée, pas une démonstration isolée.

De la réponse impressionnante au service fiable

La production exige moins de magie et davantage de preuves : corpus gouverné, recherche évaluée, droits, refus, observabilité et exploitation. C’est cette discipline qui transforme un LLM en outil de travail.

Partitech développe des chaînes RAG, des intégrations de modèles et des composants open source autour de PHP, Mistral et PostgreSQL/pgvector. L’accompagnement peut couvrir le cadrage, le prototype, l’évaluation, la sécurité et la mise en production.

Parlons de votre projet

Cadrer ou industrialiser votre assistant documentaire avec Partitech. Contactez Partitech.