Comment Créer un RAG : le Guide Pas à Pas (Local et Souverain)

Un modèle d'IA ne connaît pas vos documents : posez-lui une question sur votre documentation interne, et il invente une réponse. Le RAG résout ce problème en lui fournissant vos documents au moment de la question — sans réentraînement, et sans que ces documents quittent votre infrastructure.

Ce guide explique comment créer un RAG de A à Z, étape par étape, dans une version 100 % locale : vos données restent chez vous. Accessible que vous soyez développeur ou non.

Qu'est-ce qu'un RAG, et pourquoi en créer un ?

Un RAG (Retrieval-Augmented Generation, ou génération augmentée par récupération) est une technique qui permet à un modèle de langage de répondre à partir de vos documents. Au lieu d'espérer que le modèle « connaisse » vos données, le système va chercher les passages pertinents dans votre base documentaire et les injecte dans le prompt. Le modèle rédige alors sa réponse à partir de ce contexte, en citant ses sources.

Nous détaillons le concept dans notre article interroger vos documents avec une IA locale. Ici, on passe à la pratique : comment le construire. Mais d'abord, un rappel utile — le RAG n'est pas la solution à tout.

Trois qualités expliquent pourquoi le RAG s'est imposé pour exploiter des données propriétaires. Il est à jour : la base se met à jour indépendamment du modèle. Il est vérifiable : la réponse cite ses sources, l'utilisateur remonte au document d'origine. Et il est économe : pas de réentraînement, juste trois briques exécutables en local — donc conforme au RGPD par construction, puisque rien ne sort de votre infrastructure.

L'architecture d'un RAG : deux phases distinctes

Avant de construire, il faut comprendre qu'un RAG fonctionne en deux temps qui ne s'exécutent pas au même moment. C'est le modèle mental le plus important à avoir en tête.

La phase d'indexation est un traitement par lots : elle prépare vos documents à l'avance. La phase de recherche s'exécute, elle, à chaque question de l'utilisateur. Comprendre cette séparation évite bien des confusions dans la suite.

Les 4 décisions qui déterminent la qualité

Avant même d'écrire une ligne de code, quatre choix pèsent plus que tous les autres sur la qualité de votre RAG. Les garder en tête dès le départ évite des refontes coûteuses.

Collecter et préparer vos documents

Tout commence par un corpus propre. C'est l'étape la plus négligée, et pourtant la qualité de votre index en dépend entièrement : des documents mal extraits produisent une recherche incohérente, quelle que soit la suite.

Collecter consiste à rassembler vos sources : PDF, fichiers Word, pages d'un wiki interne, exports Markdown. Nettoyer consiste ensuite à retirer ce qui parasite le texte — balises HTML résiduelles, en-têtes et pieds de page répétés, caractères d'encodage cassés. Un PDF converti brutalement en texte contient souvent des numéros de page et des sauts de ligne au milieu des phrases : à nettoyer avant d'aller plus loin.

Découper les documents en chunks (le chunking)

Un LLM ne peut pas ingérer un document de 80 pages d'un coup — et de toute façon, on ne veut lui donner que les passages pertinents. Le chunking découpe chaque document en morceaux digestes.

La stratégie la plus courante pour débuter est le découpage récursif : on coupe en respectant la structure (paragraphes, phrases) plutôt qu'au milieu des mots, avec une taille cible de quelques centaines de mots. Le point crucial est le recouvrement (overlap) : chaque chunk reprend les dernières lignes du précédent, pour ne pas perdre le contexte à la frontière entre deux morceaux.

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,        # taille cible (caractères)
    chunk_overlap=100,     # recouvrement entre chunks
    separators=["\n\n", "\n", ". ", " "]
)
chunks = splitter.split_text(mon_document)

Pour aller plus loin, le chunking sémantique découpe selon le sens (changements de sujet) plutôt que selon une taille fixe. Plus fin, mais plus complexe : gardez-le pour une v2.

Générer les embeddings en local

Un embedding transforme un texte en une liste de nombres (un vecteur) qui capture son sens. Deux textes proches par le sens ont des vecteurs proches dans l'espace — c'est ce qui permet la recherche par similarité. C'est le cœur du RAG.

La plupart des tutoriels utilisent l'API d'embedding d'OpenAI. Problème : vos documents partent alors chez OpenAI. Pour un RAG souverain, on génère les embeddings en local avec Ollama, grâce à un modèle dédié comme nomic-embed-text — gratuit, rapide, et qui ne fait sortir aucune donnée.

# Télécharger le modèle d'embedding
ollama pull nomic-embed-text

# En Python, générer un embedding
import ollama
vecteur = ollama.embeddings(
    model='nomic-embed-text',
    prompt='Le texte de mon chunk à encoder'
)

Ce modèle fonctionne bien en multilingue, donc pour du français. Pour installer Ollama et comprendre son fonctionnement, suivez notre guide complet d'installation d'Ollama.

Stocker les vecteurs dans une base vectorielle

Une fois vos chunks transformés en vecteurs, il faut les ranger dans une base vectorielle — une base de données spécialisée dans la recherche par similarité. C'est elle qui, à chaque question, retrouvera les vecteurs les plus proches en quelques millisecondes.

Trois options locales reviennent selon votre besoin :

Pour un premier RAG, ChromaDB offre le meilleur compromis simplicité/fonctionnalités. Toutes ces bases s'installent et tournent sur votre infrastructure, sans aucun appel externe.

Rechercher et générer la réponse

C'est le moment où tout s'assemble. À chaque question de l'utilisateur, le système enchaîne : encoder la question (avec le même modèle d'embedding que pour les documents — c'est impératif), rechercher les chunks les plus proches dans la base, les injecter dans le prompt, et laisser le LLM local rédiger la réponse.

# 1. Encoder la question (même modèle qu'à l'indexation)
q_vec = ollama.embeddings(model='nomic-embed-text',
                          prompt=question)

# 2. Récupérer les K chunks les plus proches
chunks = base_vectorielle.search(q_vec, top_k=4)

# 3. Construire le prompt avec le contexte
contexte = "\n\n".join(chunks)
prompt = f"""Réponds à la question en utilisant UNIQUEMENT
le contexte ci-dessous. Si la réponse n'y est pas,
dis-le clairement.

Contexte :
{contexte}

Question : {question}"""

# 4. Générer la réponse avec un LLM local
reponse = ollama.chat(model='mistral',
    messages=[{'role': 'user', 'content': prompt}])

La consigne « utilise UNIQUEMENT le contexte » est essentielle : elle bride le modèle pour qu'il ne réponde pas de mémoire (donc n'invente pas) quand l'information n'est pas dans vos documents. C'est votre premier garde-fou contre les hallucinations.

Ajouter une interface (avec ou sans code)

Un RAG en ligne de commande, c'est bien pour tester. Pour le rendre utilisable par vos équipes, il lui faut une interface de chat. Deux chemins selon votre profil.

Option développeur : une API + une interface web

Vous exposez votre RAG via une API (avec FastAPI par exemple) et branchez une interface de chat dessus. Contrôle total, personnalisation complète, mais du développement à prévoir.

Option sans code : Open WebUI

Si vous ne voulez pas coder, Open WebUI offre une interface façon ChatGPT dans laquelle vous déposez vos documents, et le RAG se fait automatiquement, en local, connecté à Ollama. C'est le moyen le plus rapide d'avoir un RAG fonctionnel sur vos documents sans écrire une ligne de code — nous détaillons cette approche dans notre guide RAG avec Open WebUI.

Aller plus loin : recherche hybride, reranking, évaluation

Votre premier RAG fonctionne, mais répond parfois à côté ? Trois techniques font passer un RAG « correct » à « fiable ».

La recherche hybride combine la recherche sémantique (par le sens) avec une recherche par mots-clés (BM25). La première capte les reformulations, la seconde rattrape les termes exacts — codes produits, références légales, noms propres — que le sémantique seul manque. C'est souvent le gain de qualité le plus rentable.

Le reranking ajoute une deuxième passe : après avoir récupéré une vingtaine de chunks candidats, un second modèle spécialisé les réordonne par pertinence réelle, et on ne garde que les meilleurs. Ça élimine le bruit avant la génération.

Enfin, l'évaluation : sans mesure, vous pilotez à l'aveugle. Constituez un jeu d'une trentaine de questions dont vous connaissez les bonnes réponses, et mesurez à chaque modification si votre RAG s'améliore ou régresse. C'est ce qui distingue un RAG bricolé d'un RAG maîtrisé.

Les pièges courants à éviter

Ces erreurs reviennent systématiquement sur un premier RAG. Les connaître à l'avance vous fera gagner des heures.

Créer son RAG soi-même ou se faire accompagner ?

Monter un RAG de démonstration est à la portée de tout développeur motivé, et Open WebUI permet même de s'en passer pour un premier test. Mais un RAG fiable, en production, connecté à vos outils, avec gestion des droits d'accès et évaluation continue, demande de l'expertise.

La question n'est pas « est-ce difficile ? » mais « où voulez-vous mettre votre temps ? ». Si le RAG est un projet stratégique pour votre PME — assistant sur vos procédures, support technique sur vos manuels, recherche dans vos contrats — un accompagnement vous fait gagner des semaines et vous évite les pièges ci-dessus. Et surtout, il garantit que toute l'architecture reste souveraine : vos documents ne quittent jamais votre infrastructure, contrairement aux solutions RAG cloud clés en main qui les envoient sur des serveurs tiers.

FAQ — Créer un RAG