Chatbot RAG : tout ce qu’il faut comprendre avant de se lancer

Le RAG est probablement l’une des architectures les plus utiles que l’IA générative a rendues accessibles ces deux dernières années. Un chatbot RAG bien conçu peut transformer la façon dont vos collaborateurs ou clients accèdent à l’information — à condition de comprendre ce qui se passe sous le capot. Avant d’aller plus loin, il faut comprendre ce qu’est le RAG vraiment — et ce qu’il n’est pas.

Ce qu’est le RAG — et pourquoi c’est important

RAG signifie Retrieval-Augmented Generation — en français : génération augmentée par la récupération. Derrière ce terme un peu technique se cache une idée simple : au lieu de demander à un modèle de langage (comme Claude ou GPT-4) de répondre uniquement à partir de ce qu’il a appris lors de son entraînement, on lui fournit du contexte pertinent au moment où la question est posée.

Le RAG n’est pas une technologie réservée aux chatbots. C’est une brique d’architecture générique utilisable dans de nombreux contextes :

• Génération de documents — contrats, rapports, emails personnalisés générés à partir de vos propres modèles et données
• Aide à la décision — un outil qui, face à une situation, récupère les précédents, les procédures applicables, les contraintes réglementaires pertinentes
• Audit et conformité — vérifier si une pratique est conforme à un référentiel (RGPD, ISO, politique interne)
• Synthèse de veille — à partir d’un flux d’articles ingérés, répondre à “quoi de neuf sur ce sujet cette semaine”
• Routage intelligent — qualifier automatiquement un ticket ou un email entrant en s’appuyant sur une base de règles métier

Ce que tous ces usages ont en commun : la même infrastructure de base. Seule la couche de sortie change.

Parmi tous ces usages, le chatbot est le plus fréquent — et le plus visible. C’est celui que nous allons détailler dans cet article, car il concentre toutes les problématiques de l’architecture RAG : qualité des sources, découpage, pertinence de la récupération, et surveillance en continu.

Comment fonctionne un chatbot RAG en pratique

Un chatbot RAG n’est pas un simple bouton “connecter un LLM à mes documents”. C’est un pipeline en plusieurs étapes, qui implique plusieurs systèmes distincts.

Quand un utilisateur pose une question, voici ce qui se passe réellement :

1. L’interface (votre site, votre app) envoie la question à un webhook
2. Un workflow d’orchestration (n8n, Zapier, LangChain…) reçoit cette question et pilote la suite
3. Un agent IA — une instance du LLM configurée avec un rôle et des instructions — prend en charge le traitement
4. L’agent interroge la base vectorielle pour récupérer les chunks les plus pertinents
5. L’agent compose le prompt final : instructions système + contexte récupéré + question de l’utilisateur
6. Le LLM génère la réponse à partir de ce prompt enrichi
7. La réponse remonte au workflow, qui la renvoie à l’interface

Ce schéma en couches est important à comprendre : le LLM n’accède pas directement à votre base de connaissance. C’est l’agent — piloté par le workflow — qui fait le lien entre la question et les sources. Le LLM apporte uniquement son “cerveau” : la capacité à lire des fragments de texte, à les synthétiser, et à formuler une réponse cohérente en langage naturel.

Ce que ça implique en termes de coûts

Chaque question posée à votre chatbot déclenche au minimum deux appels au LLM :

• Un appel pour transformer la question en embedding (calcul du vecteur de recherche)
• Un appel pour générer la réponse à partir des chunks récupérés

Ces coûts sont faibles — de l’ordre de quelques fractions de centime par question avec les modèles courants. Mais ils ne sont pas nuls. Sur un chatbot très sollicité, ils peuvent s’accumuler. Il faut également compter le coût d’ingestion de la base de connaissance (un appel d’embedding par chunk lors de la création ou mise à jour).

La base de connaissance : de quoi parle-t-on ?

La base de connaissance, c’est l’ensemble des documents que vous voulez que votre chatbot soit capable de mobiliser. Cela peut être :

• Des articles de blog ou de documentation
• Des fiches produit ou service
• Des procédures internes
• Des FAQ existantes
• Des guides ou manuels
• Des politiques d’entreprise

Ces documents doivent être préparés avant d’être ingérés. Et c’est là que le format compte énormément.

Pourquoi le Markdown est le format idéal pour alimenter un RAG

Le Markdown est un format texte structuré, léger et lisible. Il utilise des conventions simples — # pour les titres, ** pour le gras, - pour les listes — pour donner de la structure à un document sans la lourdeur du HTML ou la complexité du XML.

Pour un système RAG, c’est le format de prédilection pour plusieurs raisons.

La structure sémantique est explicite. Un titre ## Comment réinitialiser votre mot de passe indique clairement de quoi parle le paragraphe qui suit. Lors du découpage en chunks, le modèle et le système de récupération peuvent exploiter cette information pour mieux contextualiser chaque fragment.

Le texte est propre et tokenisable. Pas de balises HTML parasites, pas de CSS injecté, pas de caractères d’encodage bizarres. Chaque token utilisé par le modèle correspond à du contenu réel — ce qui améliore la qualité des embeddings.

Les métadonnées sont faciles à intégrer. Un frontmatter YAML en tête de fichier permet d’ajouter des informations structurées (catégorie, date, auteur, statut) exploitables lors du filtrage ou du tri des résultats.

La mise à jour est simple. Contrairement à un PDF ou un document Word, un fichier Markdown se modifie avec n’importe quel éditeur, se versionne avec Git, et peut être réingéré automatiquement dès qu’il change.

Le découpage en chunks : l’étape la plus critique

Un document de 20 pages ne peut pas être injecté en entier dans un prompt — les LLM ont des limites de contexte, et plus important encore, un texte long nuit à la précision de la récupération. Il faut découper.

Un chunk est un fragment de texte autonome, suffisamment court pour être traitable, suffisamment long pour être porteur de sens.

Les différentes stratégies de découpage

Découpage fixe par nombre de tokens. On coupe tous les X tokens (512, 1024…). Simple, prévisible, mais risque de couper une phrase en plein milieu d’une idée. Un chevauchement (overlap) de 10 à 20% entre chunks consécutifs atténue ce problème.

Découpage par séparateurs sémantiques. On coupe aux niveaux ##, ###, aux sauts de paragraphe, aux puces de liste. Cette approche respecte la structure du document et produit des chunks naturellement cohérents — surtout si les sources sont en Markdown bien structuré.

Découpage récursif. On essaie d’abord de couper par sections, puis par paragraphes, puis par phrases, jusqu’à atteindre la taille cible. C’est l’approche la plus robuste et la plus utilisée en production.

Chunking par entités. On identifie des unités sémantiques — une question/réponse, une procédure complète, une définition — et on les traite comme un chunk indépendant de leur longueur. Idéal pour les FAQ ou les documentations bien structurées.

Ce qui fait un bon chunk

Un bon chunk doit pouvoir être lu de façon isolée et donner une information complète. Il doit mentionner son sujet dès les premières lignes — sans supposer que le lecteur a lu le paragraphe précédent. Il ne doit pas être trop court (moins de 100 tokens) au risque de perdre le contexte, ni trop long (plus de 1500 tokens) au risque de diluer la pertinence.

La base vectorielle : le moteur de la mémoire

Une fois vos chunks préparés, il faut les stocker sous une forme qui permet la recherche par similarité sémantique. C’est le rôle de la base vectorielle.

Chaque chunk est transformé en embedding — un vecteur de plusieurs centaines ou milliers de dimensions, produit par un modèle spécialisé (OpenAI ada-002, Cohere Embed, ou des modèles open source comme nomic-embed ou bge-m3). Ce vecteur capture le sens sémantique du texte : deux phrases qui signifient la même chose auront des vecteurs proches, même si elles n’ont pas un mot en commun.

Quand une question arrive, elle est elle aussi transformée en embedding, puis comparée à tous les vecteurs stockés. Les plus proches (au sens de la similarité cosinus) correspondent aux chunks les plus pertinents.

Les options de bases vectorielles

Pgvector (PostgreSQL). Extension de PostgreSQL qui ajoute un type de donnée vecteur et les opérations de similarité. Parfait si vous utilisez déjà Postgres ou Supabase — pas besoin d’une infrastructure supplémentaire. C’est la solution la plus pragmatique pour commencer.

Pinecone. Service managé spécialisé, très performant sur de gros volumes. Simple à intégrer, mais coût mensuel qui monte rapidement.

Weaviate / Qdrant / Chroma. Bases vectorielles open source dédiées, avec des fonctionnalités avancées (filtres, namespaces, multi-tenancy). À considérer pour des cas d’usage complexes.

Supabase + pgvector. La combinaison idéale pour les projets de chatbot RAG qui veulent tout centraliser : la base relationnelle, le stockage des chunks, les embeddings, et les métadonnées associées — dans une seule infrastructure. Supabase propose pgvector nativement sans configuration supplémentaire.

Le pipeline d’ingestion : comment alimenter le RAG

L’ingestion est le processus qui transforme vos documents sources en chunks stockés dans la base vectorielle. Ce pipeline doit être pensé dès le début, car il sera exécuté régulièrement — chaque fois que vous mettez à jour votre base de connaissance.

Un pipeline d’ingestion typique comprend :

1. Chargement : lecture des fichiers Markdown depuis un dossier, un dépôt Git, ou un CMS
2. Nettoyage : suppression des éléments non pertinents (métadonnées de déploiement, commentaires techniques)
3. Découpage : application de la stratégie de chunking choisie
4. Enrichissement : ajout de métadonnées à chaque chunk (source, section, date de mise à jour)
5. Embedding : appel à l’API d’embedding OpenAI ou équivalent pour transformer chaque chunk en vecteur
6. Stockage : insertion en base vectorielle avec upsert (mise à jour si le chunk existe déjà)

Ce pipeline peut être entièrement automatisé avec n8n — un orchestrateur open source qui permet de déclencher la réingestion dès qu’un fichier source est modifié. C’est d’ailleurs l’approche que nous utilisons sur ce site, comme détaillé dans notre article sur n8n, Supabase et Claude.

Gérer les mises à jour et les suppressions

L’étape la plus sous-estimée du pipeline n’est pas l’ingestion initiale — c’est la gestion du cycle de vie des documents. Un document peut être modifié, remplacé, ou tout simplement devenir obsolète. Ses chunks, eux, restent dans la base vectorielle jusqu’à ce que vous les supprimiez explicitement.

Il faut donc gérer trois cas :

• Mise à jour : un document change de contenu → supprimer les anciens chunks liés à ce fichier, puis réingérer
• Suppression : un document est retiré de la base de connaissance → supprimer tous ses chunks
• Archivage : un document est remplacé par une version plus récente → supprimer l’ancienne version et ingérer la nouvelle

Pour rendre cela possible, chaque chunk doit stocker en métadonnée l’identifiant de son document source (nom de fichier, URL, ou ID interne). Sans cela, impossible de retrouver et nettoyer tous les fragments d’un document donné.

Le registre des fichiers ingérés

La gestion du cycle de vie repose sur un prérequis simple mais souvent négligé : savoir exactement ce qui est ingéré dans votre base.

Tenez à jour un registre des fichiers ingérés — une table en base de données ou un simple fichier de suivi — contenant pour chaque document : son identifiant, son chemin ou URL, sa date de dernière ingestion, son hash de contenu, et son statut (actif, archivé, supprimé).

Ce registre vous permet de répondre à des questions critiques :

• Ce document a-t-il été modifié depuis sa dernière ingestion ?
• Quels documents n’ont pas été revus depuis plus de 6 mois ?
• Ce fichier supprimé a-t-il bien été purgé de la base vectorielle ?

Sans ce registre, votre base de connaissance devient rapidement un mélange de contenu à jour et de contenu périmé — et vous n’avez aucun moyen de distinguer les deux.

La surveillance : ce qu’il faut monitorer en production

Déployer un chatbot RAG n’est pas une action ponctuelle. C’est un système vivant qui doit être suivi de près — pas seulement pour détecter les pannes techniques, mais pour améliorer continuellement la qualité des réponses.

Surveiller les questions posées

Chaque question posée à votre chatbot est une donnée précieuse. Elle révèle :

• Ce que cherchent vraiment vos utilisateurs — souvent différent de ce que vous aviez anticipé
• Les angles morts de votre base de connaissance — les sujets sur lesquels le chatbot ne trouve rien ou répond mal
• Les formulations récurrentes — qui peuvent vous aider à améliorer vos documents sources
• Les questions hors périmètre — qui indiquent soit un mauvais cadrage du chatbot, soit un besoin non couvert

Logguez systématiquement chaque question avec son timestamp, l’identifiant de session, et les chunks récupérés.

Surveiller les réponses apportées

Loguer la question ne suffit pas. Il faut aussi loguer la réponse générée, les chunks utilisés, le score de similarité des chunks récupérés, et si possible le feedback de l’utilisateur.

Un score de similarité faible (inférieur à 0.7 en cosinus normalisé) sur les chunks récupérés est un signal d’alerte : le chatbot a répondu sans trouver de contenu vraiment pertinent — ce qui augmente le risque d’hallucination ou de réponse hors sujet.

Mettre en place une boucle d’amélioration continue

La surveillance ne sert à rien si elle ne débouche pas sur des actions. Mettez en place une revue hebdomadaire ou mensuelle des questions sans bonne réponse. Pour chacune, posez-vous deux questions : est-ce que l’information existe dans ma base et n’a pas été bien récupérée (problème de chunking ou d’embedding) ? Ou est-ce que cette information n’existe tout simplement pas encore (problème de couverture documentaire) ?

Les points de vigilance en production

La fraîcheur de la base de connaissance. La base vectorielle ne se met pas à jour toute seule. Chaque document modifié, archivé ou supprimé doit être traité activement dans le pipeline — sans quoi les anciens chunks continuent de polluer les résultats. Automatisez la détection des changements (via hash ou date de modification) et planifiez une revue périodique du registre des fichiers ingérés pour identifier ceux qui n’ont pas été revus depuis trop longtemps.

La gestion des périmètres. Définissez clairement ce que le chatbot doit et ne doit pas traiter. Un chatbot qui répond à tout, y compris aux questions hors périmètre, nuit à la confiance des utilisateurs. Implémentez un garde-fou : si le score de similarité maximal est inférieur à un seuil, le chatbot doit indiquer qu’il ne dispose pas de l’information plutôt que de répondre en improvisant.

La transparence sur les sources. Afficher les sources utilisées pour générer la réponse augmente la confiance et permet à l’utilisateur de vérifier l’information. C’est aussi un outil de débogage précieux.

La cohérence des embeddings. Le modèle utilisé pour créer les embeddings lors de l’ingestion doit être le même que celui utilisé lors de la recherche. Si vous changez de modèle, vous devez réingérer toute la base.

Ce que l’IA ne fait pas à votre place

Le RAG est une architecture puissante, mais elle amplifie la qualité de vos documents sources autant qu’elle en révèle les faiblesses. Un document mal rédigé, mal structuré ou incomplet produira des chunks médiocres, des embeddings peu discriminants et des réponses décevantes.

Avant de construire l’infrastructure technique, posez-vous les bonnes questions : vos documents sont-ils à jour ? Sont-ils rédigés de façon claire et autonome ? Couvrent-ils les sujets que vos utilisateurs vont réellement aborder ?

Un chatbot RAG n’est pas un raccourci pour éviter de structurer votre connaissance. C’est un outil pour la rendre accessible — à condition qu’elle existe déjà, qu’elle soit fiable et bien organisée.

La règle d’or : garbage in, garbage out. L’IA ne compense pas la médiocrité des sources. Elle la distribue à grande échelle. C’est le même principe que pour n’importe quel système d’information — comme nous l’expliquons dans notre article sur la maîtrise du système d’information en PME.

Un exemple de plus qui rappelle l’importance de maîtriser sa data

Le chatbot RAG illustre parfaitement un principe qui traverse toute la transformation numérique des entreprises : la qualité de vos outils dépend directement de la qualité de votre data.

Mettre en place un RAG, c’est prendre une décision d’architecture. Choisir sa stratégie de chunking, sa base vectorielle, son modèle d’embedding, son pipeline de mise à jour — ce sont des choix techniques qui ont des conséquences concrètes sur la fiabilité des réponses, sur les coûts, sur la maintenabilité du système dans la durée. Mal pensée, cette architecture peut générer exactement le problème qu’elle était censée résoudre : des informations fausses distribuées avec assurance, à grande échelle.

C’est pourquoi la facilité est un piège. Les outils no-code, les tutoriels en 10 minutes, les plateformes qui promettent un chatbot “prêt en quelques clics” — ils permettent d’obtenir quelque chose qui fonctionne en apparence. Mais ils ne remplacent pas la compréhension de ce qui se passe sous le capot : comment les chunks sont formés, comment les vecteurs sont comparés, ce qui se passe quand un document est supprimé et que ses chunks restent orphelins en base.

Comprendre ces mécanismes, c’est ce qui vous permettra de faire les bons choix au moment où ils comptent — lors de la conception, pas lors du premier incident en production.

Si vous n’avez pas les compétences en interne pour penser cette architecture de chatbot RAG, faites-vous accompagner. Pas nécessairement pour sous-traiter entièrement — mais pour cadrer les choix structurants, éviter les erreurs de conception, et garder la main sur votre système une fois déployé. Un chatbot RAG qui répond mal, ou pire, qui répond faux avec confiance, nuit davantage à votre image qu’une page FAQ bien tenue.

Pour aller plus loin sur les enjeux de gouvernance des données et d’architecture SI dans les PME, consultez nos articles sur la cartographie des documents du SI et sur les niveaux d’IA accessibles aux PME.