📚RAG sans blabla · quand vous en avez VRAIMENT besoin (et quand c'est jeter l'argent par les fenêtres)

Quand le besoin apparaît-il ? (le moment exact)

Le besoin surgit à un moment bien précis : quand votre IA doit travailler avec beaucoup d'informations en même temps et qu'elle commence à faillir. Signaux typiques : vous chargez 30 PDF et l'IA « oublie » la moitié ; vous lui collez un long manuel et elle répond en mélangeant les choses ou en inventant ; ou vous devez recoller le même gros document dans chaque conversation parce qu'elle ne le retient pas. C'est là que quelqu'un vous dit « il te faut un RAG ».

Le RAG en clair (sans un seul mot technique)

RAG signifie « génération augmentée par récupération ». Ça sonne horrible, mais l'idée est simple : au lieu de donner TOUS vos documents à l'IA à chaque fois (hors de prix et impossible s'ils sont nombreux), vous stockez vos documents à part et, quand vous posez une question, un moteur de recherche récupère uniquement les petits morceaux pertinents et les passe à l'IA pour qu'elle réponde avec ça. Chercher d'abord, répondre ensuite.

Le grand avantage supplémentaire : comme l'IA répond à partir de morceaux concrets de VOS documents, elle peut vous citer la source (« ça vient du manuel, page 12 »). C'est ce qui tue les inventions : si ce n'est pas dans vos documents, elle ne l'invente pas.

Le grand bénéfice : le RAG économise BEAUCOUP de tokens (quand le corpus est grand)

Voici la raison principale de l'existence du RAG, et elle n'est pas mineure : l'économie d'argent. Chaque mot que vous donnez à l'IA coûte des tokens, et les tokens coûtent de l'argent. Si vous avez 5.000 pages de documents et que vous les collez entières à CHAQUE question, vous payez une fortune (et souvent, elles ne tiennent même pas). Le RAG résout ça : au lieu d'envoyer les 5.000 pages, il n'envoie que les 3 ou 4 petits morceaux qui répondent réellement à votre question.

Pourquoi les appelle-t-on « chunks » ? (la pièce clé du RAG)

Chunk en anglais veut dire « morceau » ou « bout ». C'est la pièce centrale du RAG, alors ça vaut le coup de la comprendre. Vos documents ne sont PAS stockés entiers : ils sont découpés en petits morceaux — chaque chunk fait en général un paragraphe ou deux — et chaque morceau est stocké avec une sorte d'« empreinte de son sens ».

La règle d'or · avez-vous vraiment besoin du RAG ?

Voici la donnée que presque aucun « gourou » ne vous dit, et elle vient d'Anthropic elle-même (les créateurs de Claude). La règle est étonnamment généreuse :

Pourquoi est-ce si important ? Parce que 500 pages, c'est énorme pour la plupart des projets. Votre charte de marque, vos modèles, les politiques de votre activité, quelques livres… ça tient normalement. Et si ça tient, monter un RAG revient à se compliquer la vie sans raison. Le RAG, c'est pour quand vous dépassez vraiment cette taille : des bibliothèques immenses, des milliers de documents, des données qui changent tout le temps.

L'échelle complète (pour que vous voyiez où s'insère le RAG)

Le RAG n'est ni la première ni la dernière étape — c'est un barreau dans une échelle. Montez-la dans l'ordre, ne sautez pas de barreaux par effet de mode :

Les 3 façons d'implémenter un RAG (choisissez selon votre niveau)

Il n'y a pas une seule manière de monter un RAG : il y en a trois, du moins au plus d'effort et de puissance. L'important, c'est de choisir celle qui vous correspond vraiment, pas la plus impressionnante. Les voici, et on les prend ensuite une par une :

Façon 1 · Monter un RAG SANS écrire de code (la voie facile)

Si vous avez passé le filtre et que le RAG vous concerne vraiment, bonne nouvelle : vous n'avez pas besoin de programmer ni de monter des bases de données. Il existe des outils où vous glissez vos documents et c'est bon, vous avez déjà votre moteur de recherche intelligent avec citations. En voici deux que tout le monde peut utiliser aujourd'hui :

Façon 2 · Avec un repo open-source (plus de contrôle)

Quand votre projet grandit ou que vous voulez garder le contrôle sur votre propre serveur, il existe des outils open-source puissants et gratuits. Les deux plus accessibles pour les non-experts (votre IA vous aide à les installer) :

Je veux monter un RAG open-source sur mes documents en utilisant un de ces repos :
- RAGFlow (https://github.com/infiniflow/ragflow) — RAG visuel, idéal si je veux quelque chose de complet.
- AnythingLLM (https://github.com/Mintplex-Labs/anything-llm) — appli de bureau, locale et privée.

Guide-moi étape par étape en langage simple, en supposant que je ne sais pas programmer :
1. Aide-moi à choisir lequel me convient selon mon cas : [décris tes documents, si tu veux que tout soit local/privé, et ton système d'exploitation].
2. Dis-moi comment l'installer (avec ses prérequis, ex. Docker) et fais-le toi-même là où tu peux.
3. Aide-moi à charger mes documents et à créer la base de connaissances.
4. Configure-le pour qu'il réponde UNIQUEMENT avec ce qui est dans mes documents et cite TOUJOURS la source.
5. Donne-moi 3 questions de test pour confirmer qu'il lit bien mes documents.

Si une étape doit être faite à la main par moi, dis-le-moi avec des instructions exactes.

Façon 3 · Le RAG d'une super-application (voici comment fonctionne le nôtre)

La troisième façon est la plus sérieuse : quand vous construisez une super-application — une plateforme avec énormément d'informations et beaucoup d'utilisateurs — aucun outil clé en main ne suffit. Là, vous construisez votre propre moteur de RAG sur mesure. C'est du niveau ingénieur (vous le faites vous-même ou votre équipe en dirigeant des agents de code), mais on vous le montre de l'intérieur, sans blabla, pour que vous voyiez jusqu'où ça peut aller : voici comment fonctionne le moteur de RAG que nous utilisons dans nos applications.

Copiez-le et collez-le à votre agent de code (Claude Code, Cursor) quand vous partez construire un RAG sur mesure. Il intègre les décisions qui fonctionnent chez nous, pour qu'il démarre sur un terrain solide au lieu d'improviser :

Tu vas m'aider à construire un RAG sur mesure pour une application à grande échelle. N'écris PAS encore de code. D'abord, PLANIFIE avec moi, car l'erreur la plus coûteuse, c'est de coder sans avoir décidé l'architecture.

ÉTAPE 1 — Interviewe-moi (une question à la fois, en langage simple) :
- Quelle information le RAG va-t-il indexer et combien ? (types de document, volume approximatif)
- Combien d'utilisateurs et combien de requêtes par jour prévois-tu ?
- Les données changent-elles souvent ? Dois-je supprimer/mettre à jour des chunks ?
- Est-ce multi-locataire (plusieurs clients avec des données séparées) ? Y a-t-il des données sensibles ?
- Quel stack j'utilise déjà (base de données, langage, où c'est hébergé) ?

ÉTAPE 2 — Propose l'architecture, en utilisant ces décisions éprouvées comme point de départ (et dis-moi si dans mon cas il vaut mieux les changer et pourquoi) :
- Base vectorielle : PostgreSQL + pgvector avec index HNSW (si j'utilise déjà Postgres/Supabase, réutilise-le).
- Embeddings : un modèle économique ou gratuit (ex. Gemini), en gardant la dimension que tu choisis.
- Chunking : morceaux d'environ 200 tokens avec un peu de chevauchement, et garde les métadonnées (source, date, section).
- Recherche hybride : combine vectorielle + texte exact, et un re-ranking pour faire remonter le plus pertinent.
- Isolation : si c'est multi-locataire, filtre TOUJOURS par l'id du client dans chaque requête.

ÉTAPE 3 — Donne-moi un PLAN PAR PHASES (quoi construire en premier, quoi laisser pour après) avec une phase minimale qui fonctionne de bout en bout avant d'optimiser.

ÉTAPE 4 — Liste les 5 erreurs les plus courantes dans un RAG de production et comment les éviter dès le premier jour (ex. ne pas filtrer par locataire, chunks mal découpés, ne pas gérer les mises à jour, faire confiance sans citer la source, ne pas mesurer la qualité des réponses).

Quand on aura approuvé le plan, c'est seulement là qu'on commence à construire la phase 1, étape par étape, et on sauvegarde la progression sur GitHub à chaque phase qui fonctionne.

Prompt 1 · Diagnostic — ai-je besoin d'un RAG ou non ?

Avant de monter quoi que ce soit, laissez votre IA vous dire à quel palier vous êtes vraiment. Copiez-le et collez-le à ChatGPT, Claude ou votre agent :

Je veux savoir si j'ai vraiment besoin d'un RAG ou si je me complique la vie. Pose-moi ces questions une par une, attends ma réponse, et à la fin dis-moi à quel palier je suis et pourquoi :

1. Combien de documents j'ai, approximativement, et de quelle taille ? (un calcul grossier du total de pages)
2. Cette information change-t-elle souvent ou est-elle stable ?
3. Ai-je besoin qu'elle me cite la source de chaque réponse ?
4. Est-ce pour moi seul, ou pour une appli qu'utiliseront beaucoup de personnes ?
5. Quel outil d'IA j'utilise aujourd'hui ?

Règles pour ta recommandation :
- Si tout mon matériel tient dans ~500 pages (environ 200.000 tokens), dis-moi que je n'ai PAS besoin de RAG : que je colle tout dans le contexte, c'est plus simple et plus précis.
- Si c'est clairement plus que ça, ou que ça change beaucoup, ou que c'est pour beaucoup d'utilisateurs, recommande-moi le RAG et dis-moi si la voie sans code (NotebookLM / Custom GPT) me suffit ou s'il me faut quelque chose d'open-source.
- Ne me pousse pas vers la sur-ingénierie. Recommande-moi le palier le PLUS SIMPLE qui résout mon cas, et justifie-le.

Prompt 2 · Montez votre mini-RAG sans code et à l'épreuve des inventions

Si le diagnostic a dit « oui, RAG sans code », ce prompt vous guide pour le monter et, surtout, pour vérifier qu'il lit bien vos documents et n'invente pas :

Je vais monter un RAG sans code pour consulter mes documents. Guide-moi étape par étape, en langage simple, en supposant que je ne sais pas programmer.

1. Recommande-moi entre NotebookLM (gratuit) et un Custom GPT de ChatGPT selon mon cas : j'ai [décris tes documents : combien, de quel type, pour quoi je vais les consulter].
2. Dis-moi les étapes exactes (avec les clics) pour créer l'espace et charger mes documents.
3. Rédige-moi les consignes que je dois lui donner pour qu'il réponde UNIQUEMENT avec ce qui est dans mes documents, cite la source, et dise clairement « ce n'est pas dans les documents » au lieu d'inventer.
4. Donne-moi 3 questions de test pour confirmer qu'il lit vraiment mes documents (et ne répond pas de mémoire générale).
5. Dis-moi comment me rendre compte s'il invente, et quoi ajuster si ça arrive.

Fais simple. Si quelque chose ne peut être fait que par moi sur le web, dis-le-moi avec les clics exacts.

Erreurs typiques (pour ne pas tomber dedans)

Le palier suivant · d'une pièce au cerveau complet

Le RAG est une pièce puissante, mais ce n'est qu'une seule : il cherche dans vos documents. Quand vous construisez une vraie appli, cette appli a en plus besoin de se souvenir de chaque utilisateur et, parfois, de comprendre comment tout se connecte. Les trois choses réunies — RAG + mémoire + graphe — forment ce qu'on appelle un brain, le cerveau propre de votre appli. C'est la prochaine ressource, et elle réunit tout ce que vous avez vu.