Le RAG en développement web est la technique qui permet de brancher un modèle de langage sur vos propres documents, sans passer par un ré-entraînement coûteux. C’est la brique la plus accessible pour commencer à intégrer de l’IA dans une application. Cet article pose les bases pour un développeur qui découvre le sujet.
Le RAG c’est quoi ?
RAG signifie Retrieval-Augmented Generation, ou génération augmentée par récupération. C’est une technique qui permet à un modèle de langage (LLM) de répondre à partir de vos propres documents, sans avoir besoin de ré-entraîner le modèle.
Concrètement, quand l’utilisateur pose une question à votre application, le système va d’abord chercher les passages pertinents dans une base documentaire, puis les transmet au LLM pour qu’il formule une réponse. L’origine du concept remonte à un article de recherche publié par Meta AI en 2020, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al.).
Pourquoi un LLM seul ne suffit pas pour une application web ?
Un LLM comme GPT-4 ou Claude est entraîné sur un corpus figé. Il ne connaît ni votre documentation interne, ni votre base clients, ni vos articles publiés la semaine dernière. Si vous l’interrogez sur ces contenus, il va souvent inventer une réponse plausible ou parfois complètement à l’ouest. C’est ce qu’on appelle une hallucination.
La connaissance figée du modèle
Un LLM apprend pendant son entraînement, puis sa connaissance s’arrête à une date précise. Pour un projet web, c’est un problème car vos contenus évoluent, vos fiches produits changent et sont mises à jour. Selon la documentation d’AWS, le RAG permet justement aux développeurs de fournir au modèle des informations récentes ou propriétaires sans passer par un ré-entraînement coûteux.
Le problème des hallucinations
Quand un modèle ne sait pas, il préfère rarement l’avouer. Il va donc générer une réponse qui semble crédible, et la délivrer avec un tel aplomb qu’il peut induire l’utilisateur en erreur. Pour une application de service client, une FAQ dynamique ou un assistant documentaire, c’est inacceptable. Le RAG réduit ce risque en ancrant la réponse dans des sources vérifiables, un principe désigné en anglais par le terme grounding ou l’ancrage en bon français.
« Le RAG est un framework d’IA qui récupère des faits depuis une base de connaissances externe pour ancrer les grands modèles de langage (LLM) sur les informations les plus précises et à jour. »
– Luis Lastras, directeur des technologies du langage, IBM Research.
Comment fonctionne un pipeline RAG, étape par étape ?
Un système RAG se compose de deux grandes phases : une phase d’ingestion hors-ligne qui prépare les documents, et une phase d’exécution en temps réel qui répond à chaque question utilisateur. Le pipeline complet suit toujours la même logique, quels que soient les outils utilisés.
1. L’ingestion des documents
La première étape consiste à rassembler les contenus qui serviront de base de connaissance. Cela peut être des fichiers PDF, des pages HTML scrapées, des entrées de base de données, des tickets de support ou des fichiers Markdown. Tout ce qui contient de l’information utile à votre application.
Chaque document est nettoyé, on retire le HTML parasite, on normalise les espaces, on corrige les encodages. Cette étape est ingrate mais détermine la qualité de tout ce qui suit.
2. Le découpage en chunks
Un document entier est trop long pour être exploité directement. On le découpe en morceaux appelés chunks. La taille habituelle se situe entre 300 et 1 000 tokens, avec un léger chevauchement (10 à 20 %) entre deux chunks consécutifs pour ne pas couper une idée en plein milieu.
Un chunk trop grand dilue l’information pertinente. Un chunk trop petit perd son contexte. Le bon équilibre dépend de vos données, et se trouve généralement par itération.
3. La génération des embeddings
Chaque chunk est ensuite converti en embedding, c’est-à-dire une représentation numérique sous forme de vecteur (une liste de plusieurs centaines ou milliers de nombres). Deux textes proches sémantiquement produisent des vecteurs proches dans l’espace mathématique.
C’est cette propriété qui rend la recherche possible ainsi le système ne cherche plus des mots-clés exacts, il cherche du sens.
4. La recherche dans la base vectorielle
Les embeddings sont stockés dans une base de données vectorielle, une base conçue pour retrouver rapidement les vecteurs les plus proches d’une requête donnée. Quand un utilisateur pose une question, cette question est elle-même transformée en embedding, puis comparée à tous ceux stockés.
La base renvoie les chunks les plus proches sémantiquement. En général, on récupère entre 3 et 5 chunks pour alimenter le modèle sans noyer son contexte.
5. La génération de la réponse
Les chunks récupérés sont injectés dans le prompt envoyé au LLM, avec la question originale. Le modèle ne répond plus à partir de sa seule mémoire d’entraînement, il va répondre à partir du contexte que vous venez de lui fournir.
Selon la documentation d’AWS, le résultat peut inclure des citations ou des références aux sources, ce qui permet à l’utilisateur de vérifier l’information par lui-même. C’est un gain direct en transparence.
Les briques techniques d’un RAG côté développement web
Un RAG intégré dans une application web repose sur quatre composants qui communiquent entre eux. Votre backend orchestre le tout, votre frontend envoie les requêtes et affiche les réponses. Rien de magique dans l’architecture, c’est un cycle HTTP classique avec deux appels supplémentaires.
La base vectorielle
C’est le composant qui stocke les embeddings et sait retrouver les plus proches d’une requête. Les options populaires incluent Pinecone (SaaS), ChromaDB (open source, facile à embarquer), Qdrant, Weaviate, ou l’extension pgvector pour PostgreSQL si vous voulez rester dans une base relationnelle.
Le choix dépend de votre volume de données et de vos contraintes d’hébergement. Pour un premier projet, pgvector ou ChromaDB suffisent largement.
Le modèle d’embedding
C’est le modèle qui transforme le texte en vecteur. Les options courantes sont les modèles d’OpenAI (text-embedding-3-small, text-embedding-3-large), Voyage AI, Cohere, ou des modèles open source comme BGE-M3 qui fonctionnent bien en français.
Point de vigilance : une fois que vous avez indexé votre corpus avec un modèle, changer de modèle impliquera de tout ré-indexer. Le choix initial vous engage.
Le LLM générateur
C’est le modèle qui rédige la réponse finale. Claude d’Anthropic, les modèles GPT d’OpenAI, Mistral, ou un modèle open source comme Llama hébergé sur vos serveurs. La plupart sont accessibles via une simple API HTTP, ce qui les rend triviaux à intégrer dans n’importe quel backend Node.js, Python ou autre.
L’orchestrateur
Le framework qui coordonne ces composants. LangChain et LlamaIndex sont les deux bibliothèques de référence, disponibles en Python et en JavaScript. Vous pouvez aussi tout câbler vous-même si votre cas d’usage est simple et c’est souvent instructif pour comprendre ce qui se passe réellement.
RAG ou fine-tuning, lequel choisir pour votre projet web ?
C’est la question la plus fréquente. Le fine-tuning consiste à ré-entraîner partiellement un modèle pour qu’il apprenne un comportement ou un style. Le RAG, lui, laisse le modèle intact et lui donne accès à de l’information au moment de la requête.
Voici les principales différences à retenir :
| Critère | RAG | Fine-tuning |
|---|---|---|
| Objectif | Accéder à des connaissances | Modifier un comportement |
| Mise à jour | Ajouter un document dans la base | Ré-entraîner le modèle |
| Coût initial | Faible | Élevé |
| Compétences requises | Dev backend, API | Machine learning |
| Traçabilité des sources | Oui | Non |
| Adapté aux données qui changent | Oui | Non |
La règle pratique, largement partagée dans la communauté est de commencer par un RAG. C’est plus rapide à déployer et plus facile à mettre à jour, et aussi, information non-négligeable, c’est moins cher à maintenir. Le fine-tuning sera pertinent quand vous voulez contrôler le style ou le ton d’un modèle, pas quand vous voulez lui apprendre des faits.
Un cas d’usage concret : un assistant qui répond sur votre documentation
Imaginez une application SaaS avec une documentation étoffée. Vos utilisateurs posent régulièrement les mêmes questions à votre support. Un assistant RAG peut prendre le relais sur les questions courantes.
Le pipeline ressemble à ceci :
- Votre documentation (fichiers Markdown du site) est découpée et indexée une fois pour toutes dans une base vectorielle.
- Quand un utilisateur pose une question dans un widget de chat, votre backend interroge la base pour récupérer les 3 ou 4 passages les plus pertinents.
- Ces passages sont envoyés au LLM avec la question, avec une instruction claire : « répondez uniquement à partir des passages fournis, et citez vos sources« .
- La réponse générée est renvoyée au frontend, avec les liens vers les pages de documentation d’origine.
L’utilisateur obtient une réponse immédiate et sourcée. Et vous pouvez mettre à jour la base en ré-indexant la documentation à chaque déploiement.
Quand utiliser un RAG, et quand s’en passer ?
Le RAG est utile dans les cas suivants :
- Vous avez un corpus documentaire important, propriétaire ou fréquemment mis à jour.
- Vous voulez que les réponses soient traçables, avec des sources citées.
- Vous construisez un assistant conversationnel sur un domaine précis (support client, FAQ, base d’informations internes, catalogue produit).
- Vous travaillez avec des données confidentielles que vous ne voulez pas envoyer brutes à un modèle public.
À l’inverse, un RAG est souvent surdimensionné si :
- Votre volume de contenu tient dans un simple prompt (quelques milliers de mots).
- Votre application a besoin de générer du texte créatif sans ancrage factuel.
- Les questions utilisateur sont prévisibles et peuvent être traitées par une FAQ classique.
Construire un RAG demande du temps, de la maintenance et une attention réelle à la qualité des données. Ce n’est pas un outil à dégainer par réflexe.
Par où commencer quand on débute en développement web
Avant d’attaquer un projet RAG, il est raisonnable de maîtriser les fondamentaux : HTML, CSS, JavaScript, un framework front-end, un backend capable d’exposer une API, et la lecture de documentation technique en anglais. Sans ces bases, intégrer un LLM à une application revient à câbler un moteur sans savoir conduire.
Une fois ces bases solides, un premier projet RAG réaliste peut être :
- Un chatbot qui répond sur le contenu d’un site personnel.
- Un assistant qui résume les articles d’un flux RSS.
- Un moteur de recherche sémantique sur un petit corpus de notes.
Ce sont des projets qui se construisent en quelques jours, avec un hébergement minimal, et qui apprennent l’essentiel du pipeline.
Enfin, un premier projet RAG peut vite partir dans tous les sens si vous vous lancez directement dans le code. Pour éviter ça, la méthode BMAD propose un cadre qui fait intervenir plusieurs agents IA spécialisés (analyste, product manager, architecte) avant d’écrire la première ligne. Un bon réflexe à prendre tôt pour ne pas accumuler de dette technique.
| Chez Oclock, la formation Concepteur d’Applications Web, notre formation la plus avancée (sans condition de diplôme) intègre désormais l’usage professionnel des outils d’IA et leur intégration dans des projets numériques. Le RAG fait partie des compétences attendues sur le marché en 2026 pour un développeur débutant qui veut se différencier. |
FAQ sur le RAG
Faut-il savoir faire du machine learning pour construire un RAG ?
Non. Un RAG s’intègre avec des appels d’API classiques. Vous n’entraînez aucun modèle vous-même : vous consommez des modèles existants via leur interface HTTP. Les compétences requises sont celles d’un développeur backend, pas d’un data scientist.
Quel langage utiliser pour un premier projet RAG ?
Python reste le plus documenté, avec LangChain et LlamaIndex très matures. JavaScript et TypeScript fonctionnent aussi parfaitement, notamment avec la version JS de LangChain. Choisissez la stack que vous maîtrisez déjà.
Combien coûte un RAG à faire tourner ?
Les coûts viennent de trois sources : les embeddings (payés une fois par chunk indexé), la base vectorielle (hébergement), et les appels au LLM (facturés au token). Un petit projet avec quelques milliers de documents peut tourner pour moins de 20 euros par mois. À grande échelle, l’optimisation des prompts et le cache deviennent importants pour maîtriser les coûts.
Un RAG peut-il se tromper ?
Oui. Si les chunks récupérés ne sont pas pertinents, le LLM va générer une réponse approximative à partir de mauvaises sources. La qualité d’un RAG dépend d’abord de la qualité de vos données et de votre stratégie de découpage. Un RAG mal conçu hallucine autant qu’un LLM généraliste.
Quelle différence entre un RAG et un agent IA ?
Un RAG cherche de l’information puis répond. Un agent peut en plus déclencher des actions : appeler une API, envoyer un email, mettre à jour une base. Les deux peuvent se combiner, mais commencez par maîtriser le RAG seul avant d’empiler des couches.
