« On voudrait un ChatGPT qui répond sur nos procédures internes. » C'est aujourd'hui la demande la plus fréquente adressée aux équipes techniques. La réponse ne consiste presque jamais à entraîner un modèle : elle consiste à mettre en place un RAG, pour Retrieval-Augmented Generation — génération augmentée par la récupération.
Le principe tient en une phrase : au lieu d'espérer que le modèle « sache », on va chercher les bons extraits de vos documents et on les lui donne au moment de la question. Voici comment cela fonctionne réellement, et surtout où les projets échouent.
Pourquoi un LLM ne connaît pas vos documents
Un grand modèle de langage a été entraîné une fois, sur des textes publics, jusqu'à une date donnée. Il ne consulte aucune base de données et n'a aucune mémoire de votre entreprise. Interrogé sur votre procédure de congés, il produira une réponse plausible — inventée. C'est le mécanisme de l'hallucination, détaillé dans notre article sur le fonctionnement des LLM.
Trois solutions existent, et une seule est raisonnable dans la plupart des cas :
| Approche | Coût | Mise à jour | Quand l'utiliser |
|---|---|---|---|
| Tout coller dans le prompt | Nul | Immédiate | Moins de 50 pages |
| RAG | Faible | Immédiate | Connaissance factuelle qui évolue |
| Fine-tuning | Élevé | Réentraînement complet | Style, format, vocabulaire métier |
Retenez la règle : le RAG apporte de la connaissance, le fine-tuning apporte du comportement. Confondre les deux est l'erreur stratégique la plus courante — et la plus chère.
Les cinq étapes d'un système RAG
Étape 1 — Découper les documents
On ne donne jamais un document entier au modèle : on le découpe en fragments de quelques centaines de mots, appelés chunks. C'est l'étape la plus déterminante de tout le système, et paradoxalement celle qu'on bâcle le plus souvent.
Un découpage aveugle tous les 500 caractères coupe les phrases au milieu et sépare une question de sa réponse. Un bon découpage suit la structure du document : un chunk par section, par article de règlement, par question de FAQ, avec un léger chevauchement entre fragments voisins.
Étape 2 — Transformer chaque fragment en vecteur
Un modèle d'embedding convertit chaque fragment en une liste de nombres qui représente son sens. Deux textes proches par le sens donnent deux vecteurs proches, même sans aucun mot commun — c'est ce qui permet de retrouver « procédure d'absence » quand l'utilisateur écrit « comment poser un congé ».
Étape 3 — Stocker et indexer
Les vecteurs sont rangés dans une base vectorielle (Chroma, Qdrant, FAISS, pgvector…). Pour un prototype de quelques centaines de fragments, un simple tableau NumPy en mémoire suffit largement : n'introduisez une base dédiée que lorsque le volume l'impose.
Étape 4 — Récupérer les bons fragments
À chaque question, on calcule le vecteur de la question et on récupère les 3 à 8 fragments les plus proches. C'est le « R » de RAG, et c'est là que se joue la qualité du système : si le bon extrait n'est pas récupéré, aucun modèle, si puissant soit-il, ne pourra répondre correctement.
Étape 5 — Générer la réponse
On construit alors un prompt qui contient les fragments récupérés et la question, avec une consigne stricte :
Réponds uniquement à partir des extraits ci-dessous.
Si l'information ne s'y trouve pas, réponds exactement :
"Cette information ne figure pas dans les documents fournis."
Cite le titre du document utilisé pour chaque affirmation.
EXTRAITS :
{extraits}
QUESTION : {question}Sans l'instruction « si l'information ne s'y trouve pas, dis-le », un modèle comblera les trous par sa connaissance générale — et personne ne verra la différence entre une réponse issue de vos documents et une réponse inventée. C'est la première chose à vérifier lors d'une recette.
Un prototype minimal
Le squelette complet tient en une trentaine de lignes. Voici la logique, volontairement dépouillée :
import numpy as np
# 1. Découpage (ici : un chunk par paragraphe, à affiner)
chunks = [p.strip() for p in document.split("\n\n") if len(p.strip()) > 80]
# 2. Vectorisation de tous les fragments (une seule fois)
vecteurs = np.array([embed(c) for c in chunks])
def repondre(question, k=4):
# 3. Vectorisation de la question
q = embed(question)
# 4. Similarité cosinus -> les k fragments les plus proches
scores = vecteurs @ q / (np.linalg.norm(vecteurs, axis=1) * np.linalg.norm(q))
top = np.argsort(scores)[-k:][::-1]
extraits = "\n\n---\n\n".join(chunks[i] for i in top)
# 5. Génération encadrée
prompt = (
"Réponds uniquement à partir des extraits ci-dessous. "
"Si l'information ne s'y trouve pas, dis-le explicitement.\n\n"
f"EXTRAITS :\n{extraits}\n\nQUESTION : {question}"
)
return generer(prompt)Les fonctions embed() et generer() appellent le modèle de votre choix — API commerciale ou modèle open source exécuté localement. Le reste ne change pas. Si le code Python ci-dessus vous semble encore difficile, commencez par les bases de Python puis par pandas.
Où les projets RAG échouent réellement
Dans notre expérience, les échecs ne viennent presque jamais du modèle de génération. Ils viennent d'ailleurs :
- Un découpage inadapté. Des fragments trop longs noient l'information ; trop courts, ils perdent le contexte. C'est le premier réglage à travailler, avant tout changement de modèle.
- Des documents mal extraits. Un PDF scanné sans OCR, un tableau Excel aplati en texte illisible, des en-têtes répétés à chaque page : la qualité de l'extraction plafonne la qualité du système.
- Aucune évaluation. Sans un jeu de 30 à 50 questions de référence avec les réponses attendues, il est impossible de savoir si une modification améliore ou dégrade le système. C'est l'investissement le plus rentable du projet.
- Pas de citation des sources. Un utilisateur professionnel n'accorde sa confiance qu'à une réponse vérifiable. Afficher le document et la section d'origine n'est pas un détail d'interface : c'est ce qui rend l'outil adoptable.
- La gestion des droits oubliée. Si tous les documents sont dans le même index, un salarié peut obtenir le contenu d'un document auquel il n'a pas accès. Le filtrage par permissions doit être pensé dès le départ, pas ajouté après.
Quatre améliorations à fort rendement
- La recherche hybride. Combiner la recherche vectorielle avec une recherche par mots-clés classique rattrape les cas où l'utilisateur cite une référence exacte (un numéro d'article, un code produit).
- Le reranking. Récupérer 20 fragments, puis les faire reclasser par un modèle spécialisé qui n'en garde que 4. Gain de pertinence très net pour un coût faible.
- La reformulation de la question. Dans une conversation, « et pour les CDD ? » n'a de sens qu'avec l'historique. Reformuler la question en une requête autonome avant la recherche corrige ce cas fréquent.
- Les métadonnées. Attacher à chaque fragment sa date, son service et sa version permet de filtrer et d'éviter qu'une procédure abrogée en 2023 ne réponde à une question de 2026.
Un RAG médiocre avec un excellent modèle donne de mauvaises réponses. Un RAG bien construit avec un modèle moyen donne de bonnes réponses. L'effort doit porter sur la récupération, pas sur la génération.
Par où commencer en entreprise
Le meilleur premier cas d'usage est interne, à faible risque et à valeur immédiate : la documentation technique d'une équipe, la base de connaissance du support, ou les procédures RH. Vous obtenez des utilisateurs qui savent repérer une mauvaise réponse — ce qui est exactement ce qu'il vous faut pour améliorer le système.
Comptez deux à trois semaines pour un prototype convaincant sur un corpus restreint, et deux à trois mois pour une mise en production avec gestion des droits, évaluation continue et interface soignée.
Pour aller plus loin sur la formulation des consignes envoyées au modèle, notre guide pratique du prompt engineering détaille les techniques directement applicables à l'étape 5.
