9 min de lecture - Stack RAG open source : le guide de démarrage pour PME

Beaucoup d'équipes se lancent dans le RAG avec une demande toute simple : « Peut-on discuter avec notre documentation ? »

Puis la réalité rattrape tout le monde. La mauvaise politique est retrouvée. Un document restreint fuite dans une réponse. Le modèle a l'air sûr de lui, mais sa source est périmée. Les utilisateurs essaient deux fois, puis retournent sur Slack.

Si vous construisez une stack RAG pour votre entreprise, l'objectif n'est pas de choisir le framework le plus tendance. L'objectif est de livrer un système fiable, conscient des permissions, et mesurable.

Ce que vous allez apprendre

• L'architecture RAG minimale viable pour une entreprise en croissance
• Les leviers de qualité qui comptent (et ceux qui ne comptent pas)
• Comment gérer les permissions et les données sensibles
• Comment évaluer un système RAG pour que la confiance ne s'érode pas
• Une checklist à utiliser avant la mise en production

L'essentiel

Une stack RAG open source fonctionne quand la recherche documentaire est traitée comme un produit : ingestion propre, filtrage conscient des permissions, et évaluation continue. Commencez par un pipeline minimal (ingestion -> indexation -> recherche -> génération), ajoutez métadonnées et citations, puis industrialisez avec du monitoring et un plan de retour arrière. La plupart des échecs viennent de la recherche documentaire et du contrôle d'accès, pas du modèle.

Stack RAG open source pour l'entreprise : partez du besoin métier

Avant de choisir des outils, répondez à deux questions :

1. Qui pose les questions (rôles, équipes, tenants) ?
2. Quel mode d'échec est acceptable (mauvaise réponse, absence de réponse, revue humaine) ?

Si vous construisez une recherche documentaire interne, « pas de réponse » est souvent acceptable. Si vous construisez un support client, « mauvaise réponse » coûte cher.

Rédigez une définition produit en un paragraphe :

• Workflow : qui demande quoi
• Sources de données autorisées
• Sources restreintes
• Ce qui doit être cité
• Quand escalader vers un humain

Cette définition fera plus pour la qualité que n'importe quel choix de framework.

Architecture minimale viable (ingestion -> indexation -> recherche -> génération)

Un système RAG basique comprend cinq briques :

1. Ingestion : d'où viennent les documents (docs, tickets, exports CRM)
2. Parsing : extraction du texte et de la structure
3. Chunking : découpage du contenu en unités récupérables
4. Indexation : stockage des embeddings et des métadonnées
5. Recherche + génération : récupération des chunks pertinents et production d'une réponse

Vous pouvez construire une stack de démarrage avec des briques open source courantes :

• Stockage : votre base de données existante (souvent Postgres) pour les métadonnées
• Index vectoriel : une base de données vectorielle ou une extension vectorielle
• Orchestration : une couche de service légère (évitez de sur-abstraire trop tôt)

Ne surinvestissez pas dans l'orchestration tant que vous ne savez pas quels problèmes de qualité vous cherchez à résoudre.

Choisir ses composants open source (évitez la dépendance aux frameworks)

Les équipes se retrouvent souvent bloquées à débattre de bibliothèques. Une meilleure approche consiste à choisir en fonction des contraintes que vous connaissez déjà :

• Où vivront les métadonnées et les ACL ? Si vous exploitez déjà Postgres de façon fiable, utilisez-le pour les métadonnées et traitez la recherche vectorielle comme une capacité, pas comme un produit à part entière érigé en dogme.
• Comment allez-vous ingérer les documents ? Si l'ingestion est fragile, tout ce qui suit donnera l'impression que « le modèle est mauvais ».
• Pouvez-vous versionner l'index ? Si vous ne pouvez pas revenir en arrière sur une construction d'index, vous n'oserez jamais améliorer le pipeline.

La stack se joue moins sur les noms de marque que sur votre capacité à l'exploiter : la déployer, la surveiller, et la déboguer quand la recherche documentaire se comporte bizarrement.

Les leviers de qualité qui font vraiment bouger les résultats

Quand les utilisateurs disent « le RAG est mauvais », ils pointent en général l'un de ces problèmes.

1) Chunking et métadonnées

Le chunking n'est pas un chiffre figé. C'est un choix de conception.

• Découpez par sens (sections, titres), pas seulement par nombre de tokens
• Ajoutez des métadonnées : source, propriétaire, date, tenant, ACL
• Stockez un identifiant de document stable et une version

Les pièges d'ingestion qui ressemblent à des « hallucinations du LLM »

Avant d'ajuster vos prompts, vérifiez l'ingestion. Ces problèmes provoquent des réponses fausses mais formulées avec assurance :

• le parseur a perdu les titres et les tableaux, et les chunks ont perdu leur sens
• d'anciens documents ont été indexés deux fois, et la recherche privilégie la mauvaise version
• les horodatages et les propriétaires sont absents, si bien qu'une politique périmée l'emporte lors de la recherche

Ajoutez une validation d'ingestion basique : comptez les documents, comparez les versions (diff), et vérifiez ponctuellement quelques sorties de parsing à chaque construction d'index.

2) Stratégie de recherche documentaire

Commencez simple, puis ajoutez de la complexité quand vous pouvez prouver qu'elle apporte quelque chose.

• Utilisez une recherche hybride quand la correspondance par mots-clés compte
• Ajoutez du reranking quand vous avez de nombreux quasi-résultats
• Imposez des citations quand la confiance est en jeu

Déboguer la recherche documentaire (une méthode simple)

Quand une réponse est fausse, isolez si c'est la recherche ou la génération qui est en cause :

1. Inspectez les chunks les mieux classés (titres, dates, propriétaires, ACL).
2. Demandez-vous : « Les bonnes sources ont-elles été récupérées ? » Si non, corrigez la recherche : métadonnées, reformulation de requête, chunking, ou filtres.
3. Si oui, demandez-vous : « La génération a-t-elle correctement utilisé les sources ? » Si non, corrigez le prompting ou les contraintes de sortie, et ajoutez des tests de grille d'évaluation (rubric tests) pour l'ancrage (grounding).

Cela évite aux équipes de changer de modèle sans fin alors que le vrai bug est « nous avons récupéré le mauvais document ».

3) Ancrage et refus de répondre

Décidez ce qui se passe quand la recherche documentaire donne des résultats faibles.

• Si la confiance est faible : répondre « je ne sais pas » + afficher les meilleures sources
• Si les sources se contredisent : montrer les deux et poser une question de clarification
• Si le document est restreint : refuser et indiquer le bon canal d'accès

Permissions et sécurité (à traiter dès le départ)

Les permissions ne sont pas une fonctionnalité d'interface. Elles font partie de la recherche documentaire elle-même.

Règles pratiques :

• Stockez les métadonnées d'ACL avec chaque chunk (tenant, équipe, visibilité du document)
• Filtrez la recherche par ACL au moment de la requête
• Anonymisez (redaction) les champs sensibles pendant l'ingestion (ou conservez-les dans un stockage séparé)
• Journalisez les accès : qui a demandé quoi, quelles sources ont été utilisées (sans divulguer le contenu)

Si vous ne pouvez pas garantir le filtrage par permissions, ne mettez pas le workflow en production.

La réalité multi-équipes et multi-tenant (les permissions sont une fonctionnalité produit)

Si plusieurs équipes utilisent le système, vous avez besoin d'un modèle de permissions dès le départ, pas d'un « on l'ajoutera plus tard ».

Approche pratique :

• stockez les identifiants tenant/équipe sur chaque chunk
• traitez le filtrage par ACL comme obligatoire dans les requêtes de recherche
• testez la gestion des permissions avec un jeu d'évaluation explicite (« l'utilisateur A ne doit pas voir le document B »)

C'est l'un des endroits où les stacks open source peuvent échouer silencieusement : tout « fonctionne » jusqu'à ce que quelqu'un voie quelque chose qu'il n'aurait pas dû voir.

Évaluation et opérations (comment préserver la confiance)

Les systèmes RAG dérivent. Les documents changent. Les politiques évoluent. Les embeddings changent.

Traitez l'évaluation comme une suite de tests unitaires.

Une boucle d'évaluation minimale

• Rassemblez 20 à 50 questions réelles
• Pour chaque question : définissez les documents (ou sections de document) source attendus
• Notez sur deux niveaux :
  • recherche documentaire : avons-nous récupéré la bonne source ?
  • réponse : la réponse est-elle correcte et ancrée dans les sources ?

Faites tourner cette suite chaque semaine et après chaque changement majeur.

Solutions de repli et retour arrière

• Prévoyez un mode de repli en recherche seule
• Prévoyez une escalade humaine pour les requêtes à haut risque
• Conservez la capacité de revenir à une version antérieure de l'index

Rafraîchissement et versioning de l'index (la partie ennuyeuse qui vous sauve)

Les entreprises en croissance évoluent vite : les documents bougent, les politiques changent, la propriété des contenus change de mains. Si le rafraîchissement de votre index se fait au coup par coup, vos utilisateurs obtiendront des réponses périmées et perdront confiance.

Deux règles pratiques :

• Définissez une cadence de rafraîchissement par source. Certaines sources peuvent se rafraîchir chaque nuit, d'autres chaque semaine. Alignez-la sur la fréquence de changement des documents sous-jacents.
• Versionnez les constructions d'index. Si une nouvelle construction dégrade la recherche documentaire, vous devez pouvoir revenir rapidement à l'index précédent.

C'est aussi là que la discipline « stack open source » prend tout son sens : vous êtes responsable de l'exploitation du pipeline, pas seulement de la construction de la démo.

Checklist de préparation RAG

Utilisez-la avant de laisser le workflow toucher à des décisions importantes.

Workflow:
- Owner named:
- Allowed data sources:
- Restricted sources:

Security:
- ACL filtering implemented and tested:
- Redaction policy:
- Audit logging:

Quality:
- Evaluation set created:
- Citation policy:
- Fallback behavior:

Operations:
- Index refresh plan:
- Monitoring and alerts:
- Rollback plan:

Traitez la recherche documentaire comme un produit

Une stack RAG open source est un système de confiance. Traitez la recherche documentaire, les permissions et l'évaluation comme des priorités de premier ordre, et vos utilisateurs s'y fieront. Traitez-la comme une démo, et elle mourra en silence. Besoin d'aide pour construire un système RAG en production ? Parlons-en.