Chatbot sur vos docs internes : j'ai monté le pipeline RAG avec n8n

Chez nous, la dernière procédure d'onboarding vivait dans un Google Doc que personne ne retrouvait. Le process de déploiement en prod ? Quelque part dans un Notion que trois personnes avaient quitté sans transmettre le lien. Un développeur m'a avoué passer 45 minutes par jour à chercher « le bon doc ». McKinsey chiffre ce gaspillage à 9,3 heures par semaine par employé. Quand votre équipe compte 15 personnes, ça représente 140 heures perdues chaque semaine. L'équivalent de 3,5 postes à temps plein qui fouillent Google Drive au lieu de bosser.

J'ai décidé d'en finir. En une après-midi, j'ai monté un pipeline RAG (Retrieval-Augmented Generation) qui connecte notre base documentaire à un chatbot IA accessible depuis Slack. Sans écrire une ligne de code serveur. Juste n8n, Supabase et une clé API Claude. Voici le montage complet — avec les erreurs que j'ai commises et les chiffres réels de ce que ça coûte.

Ce qu'on construit — et pourquoi un chatbot RAG plutôt qu'un simple prompt

Un réflexe courant : copier-coller ses docs dans ChatGPT et poser une question. Ça marche sur 5 pages. Sur 200 documents techniques, c'est inutilisable. La fenêtre de contexte sature, le modèle invente des réponses, et personne ne va copier-coller 200 fichiers chaque matin.

Le pipeline RAG résout ce problème en trois étapes. D'abord, vos documents sont découpés en morceaux (chunks) et convertis en vecteurs numériques (embeddings) stockés dans une base de données vectorielle. Ensuite, quand un utilisateur pose une question, cette question est elle aussi convertie en vecteur, et le système cherche les chunks les plus similaires. Enfin, ces chunks pertinents — et eux seuls — sont envoyés au LLM comme contexte pour générer une réponse sourcée.

Résultat : le modèle ne répond que sur la base de vos documents. Selon une méta-analyse CMARIX publiée en 2026, le RAG réduit le taux d'hallucination de 30 à 70 % selon les domaines, et les chatbots RAG atteignent 94 à 98 % de précision sur des questions spécifiques au domaine.

Voici l'architecture complète de ce qu'on va monter :

• Source : Google Drive (un dossier dédié)
• Ingestion : n8n workflow déclenché automatiquement à chaque nouveau fichier
• Découpage : chunks de 512 tokens avec 10 % d'overlap
• Embeddings : OpenAI text-embedding-3-small (0,02 $/million de tokens)
• Stockage vectoriel : Supabase avec pgvector
• Agent RAG : n8n AI Agent node + Claude Haiku 4.5
• Interface : bot Slack (ou webhook HTTP)

Prérequis : les comptes à ouvrir avant de commencer

Avant de lancer n8n, préparez vos accès. Ça prend 15 minutes.

1. n8n — soit n8n Cloud (Starter à 20 €/mois, 2 500 exécutions), soit auto-hébergé gratuitement via Docker sur un VPS à 6-12 €/mois. Pour ce tutoriel, le cloud suffit largement.
2. Supabase — compte gratuit (500 Mo de stockage, pgvector inclus). Pour une base de 200 documents, le free tier tient sans problème.
3. Clé API OpenAI — pour les embeddings uniquement (text-embedding-3-small à 0,02 $/M tokens). Embedding de 200 documents de 5 pages chacun : environ 0,03 $.
4. Clé API Anthropic — pour le LLM de réponse. Claude Haiku 4.5 à 1 $/M tokens en entrée. Alternative : GPT-4o-mini ou Mistral Small.
5. Google Cloud Console — pour créer un OAuth 2.0 qui donne à n8n l'accès à votre Drive.
6. Slack — un workspace où vous pouvez créer une app (droits admin nécessaires).

Total des comptes : 4 services. Temps de setup des credentials : 15-20 minutes. Coût récurrent pour une PME de 20 personnes : entre 0 € (n8n auto-hébergé + Supabase free) et 45 €/mois (n8n Cloud Starter + Supabase Pro).

Configurer Supabase comme base vectorielle avec pgvector

Supabase, c'est du PostgreSQL managé avec pgvector intégré. Pas besoin de Pinecone ou Weaviate — pour moins de 50 millions de vecteurs, Supabase fait le job pour une fraction du prix. Et vos données restent dans une vraie base SQL, pas un silo propriétaire.

Créer la table de stockage des embeddings

Connectez-vous à votre projet Supabase, ouvrez l'éditeur SQL et exécutez :

-- Activer l'extension pgvector
create extension if not exists vector;

-- Créer la table pour stocker les chunks et leurs embeddings
create table public.documents (
  id bigserial primary key,
  content text not null,
  metadata jsonb default '{}',
  embedding vector(1536)
);

-- Index pour la recherche par similarité
create index on public.documents
  using ivfflat (embedding vector_cosine_ops)
  with (lists = 100);

La dimension 1536 correspond au modèle text-embedding-3-small d'OpenAI. Si vous utilisez un autre modèle d'embedding, adaptez cette valeur (par exemple, 1024 pour Mistral Embed).

Créer la fonction de recherche par similarité

n8n appelle cette fonction pour trouver les chunks les plus proches d'une question :

create or replace function match_documents (
  query_embedding vector(1536),
  match_count int default 5,
  filter jsonb default '{}'
)
returns table (
  id bigint,
  content text,
  metadata jsonb,
  similarity float
)
language plpgsql
as $$
begin
  return query
  select
    documents.id,
    documents.content,
    documents.metadata,
    1 - (documents.embedding <=> query_embedding) as similarity
  from documents
  where documents.metadata @> filter
  order by documents.embedding <=> query_embedding
  limit match_count;
end;
$$;

Un détail qui m'a fait perdre 30 minutes : l'opérateur <=> mesure la distance cosinus, pas la similarité. La similarité = 1 - distance. D'où le 1 - dans le SELECT.

Connecter Google Drive et ingérer les documents dans n8n

L'objectif : chaque fois qu'un fichier est ajouté ou modifié dans un dossier Google Drive, n8n le récupère, le découpe, génère les embeddings et les stocke dans Supabase. Automatiquement.

Workflow d'ingestion — les nœuds n8n

Créez un nouveau workflow dans n8n avec cette chaîne de nœuds :

1. Google Drive Trigger — configuré sur « File Created or Updated » pour votre dossier dédié. La doc n8n détaille les options : vous pouvez surveiller un dossier spécifique et ses sous-dossiers.
2. Google Drive Download — récupère le contenu du fichier. Pour les Google Docs, exportez en texte brut (text/plain). Pour les PDF, vous aurez besoin d'un nœud intermédiaire (un Extract Text from PDF ou un appel à une API OCR).
3. Text Splitter (Recursive Character) — découpe le texte en chunks. Configuration recommandée : 512 tokens, overlap 50 tokens.
4. Embeddings OpenAI — génère un vecteur pour chaque chunk via text-embedding-3-small.
5. Supabase Vector Store (Insert Documents) — écrit chaque chunk + embedding dans votre table documents.

Premier piège rencontré : les Google Sheets et Slides ne s'exportent pas en texte brut proprement. J'ai dû ajouter un filtre en amont qui ignore ces types de fichiers et ne traite que les Docs, les PDF et les fichiers texte. Sinon, le splitter reçoit du HTML brut de Sheets — inutilisable.

Gérer la mise à jour des documents existants

Si un document est modifié, vous ne voulez pas dupliquer ses chunks dans Supabase. Ajoutez un nœud Supabase intermédiaire qui supprime les anciens chunks du document (filtrage par metadata->>'file_id') avant de réinsérer les nouveaux. C'est 3 nœuds en plus, mais ça évite que votre base ne grossisse indéfiniment et que le chatbot ne cite des versions obsolètes.

Dans le champ metadata de chaque chunk, stockez au minimum :

{
  "file_id": "1abc...xyz",
  "file_name": "procedure-onboarding-dev.gdoc",
  "updated_at": "2026-05-15T10:30:00Z",
  "source_folder": "Procédures"
}

Ces métadonnées permettent ensuite au chatbot de citer sa source (« D'après procedure-onboarding-dev.gdoc, mis à jour le 15 mai 2026 »). Un détail qui change tout pour la confiance des utilisateurs.

Stratégie de découpage : comment choisir la taille des chunks

C'est ici que j'ai perdu le plus de temps — et que la qualité du chatbot se joue à 80 %.

Mon premier essai : des chunks de 2 000 tokens. Le chatbot récupérait de gros blocs de texte, mais les réponses étaient vagues et parfois contradictoires. Le modèle noyait l'information pertinente dans un contexte trop large.

Deuxième essai : des chunks de 100 tokens. Trop petit. Le chatbot trouvait bien le passage exact, mais perdait tout le contexte autour. Une phrase isolée sur un processus n'a aucun sens sans les étapes précédentes.

Un benchmark de février 2026 sur 7 stratégies de chunking testées sur 50 articles académiques confirme mon intuition : le recursive splitting à 512 tokens arrive en tête avec 69 % de précision, contre 54 % pour le semantic chunking qui produisait des fragments de 43 tokens en moyenne.

La configuration qui fonctionne pour des docs d'entreprise

Un point souvent négligé : le français génère environ 25 % de tokens en plus que l'anglais pour le même contenu. Un paragraphe de 100 mots en français consomme ~135 tokens contre ~110 en anglais. Calibrez vos chunks en conséquence.

Quel modèle d'embedding choisir pour vos documents

Le modèle d'embedding transforme vos textes en vecteurs numériques. C'est la colonne vertébrale du RAG : un mauvais modèle d'embedding, et votre chatbot cherchera au mauvais endroit, même avec un LLM excellent.

Mon choix : text-embedding-3-small. Pour 200 documents de 5 pages, l'embedding complet coûte 0,03 $. Même avec 2 000 documents, on reste sous 0,50 $. Ce n'est pas là que se joue la facture.

Dans n8n, ajoutez un nœud « Embeddings OpenAI » et sélectionnez le modèle. Le nœud gère automatiquement le batching — pas besoin de s'en occuper.

Construire l'agent RAG conversationnel dans n8n

C'est la partie la plus satisfaisante : assembler le chatbot proprement dit. n8n propose un template de Company Knowledge Base Agent que j'ai utilisé comme base, puis adapté.

Architecture du workflow de réponse

Créez un second workflow (séparé de l'ingestion) :

1. Webhook Trigger — écoute les requêtes entrantes (Slack ou HTTP).
2. AI Agent node — le cerveau du pipeline. Configuré avec :
   • LLM : Claude Haiku 4.5 (rapide, 1 $/M tokens en input)
   • Outil « Vector Store » : pointe vers votre Supabase, table documents, avec la fonction match_documents
   • Mémoire : Window Buffer Memory (conserve les 5 derniers échanges)
3. Slack Reply — renvoie la réponse dans le thread Slack original.

Le system prompt qui fait la différence

Le prompt système de l'agent RAG est crucial. Voici celui que j'utilise :

Tu es l'assistant documentaire interne de l'entreprise.
Règles strictes :
- Réponds UNIQUEMENT à partir des documents fournis en contexte.
- Si l'information n'est pas dans les documents, dis-le clairement : "Je n'ai pas trouvé cette information dans nos docs."
- Cite toujours le nom du fichier source entre parenthèses.
- Réponds en français, de manière concise et directe.
- Ne fais JAMAIS de supposition au-delà du contenu des documents.

Sans ces gardes-fous, le modèle comble les trous avec ses connaissances générales. Avec une PME qui a des process spécifiques, c'est dangereux : le chatbot invente des étapes qui n'existent pas.

Quel LLM choisir pour le pipeline RAG

J'ai testé trois modèles sur les mêmes 50 questions issues de nos docs internes :

Surprise : Sonnet 4.6 comprenait mieux les nuances dans nos docs techniques, mais la différence ne justifiait pas le surcoût pour un usage quotidien. Haiku fait le travail 90 % du temps. Pour les questions complexes (« compare les process de déploiement entre les projets X et Y »), il galère un peu — mais c'est un cas rare.

Brancher le chatbot sur Slack en 20 minutes

Le pipeline RAG fonctionne. Reste à le rendre accessible à l'équipe là où elle travaille : Slack.

Créer l'app Slack et configurer les permissions

1. Rendez-vous sur api.slack.com/apps et créez une nouvelle app « From scratch ».
2. Dans OAuth & Permissions, ajoutez ces scopes bot :
   • app_mentions:read — déclenchement quand on mentionne le bot
   • chat:write — envoi de messages
   • channels:history — lecture du contexte du thread
3. Installez l'app dans votre workspace et copiez le Bot User OAuth Token.
4. Dans Event Subscriptions, activez les events et ajoutez l'URL webhook de votre workflow n8n (en production, pas l'URL de test).

Connecter n8n au bot Slack

Remplacez le nœud « Webhook Trigger » de votre workflow par un nœud Slack Trigger configuré sur l'événement app_mention. Quand un utilisateur tape @DocBot quelle est la procédure de déploiement ? dans un channel, le trigger se déclenche.

En sortie de l'agent RAG, ajoutez un nœud Slack - Send Message qui poste la réponse en réponse dans le même thread. Ça évite de polluer le channel principal.

Mon premier déploiement Slack a fonctionné du premier coup. C'est la partie la plus simple du pipeline. La doc n8n pour Slack est limpide.

Alternative Teams : n8n supporte aussi Microsoft Teams via le nœud dédié. La configuration est similaire, mais l'app Azure AD est un peu plus pénible à créer. Comptez 30 minutes de plus.

Combien coûte un chatbot RAG interne pour une PME

Les coûts réels, pas les estimations marketing. J'ai mesuré sur 30 jours d'usage avec une équipe de 18 personnes posant en moyenne 12 questions par jour.

Scénario 1 : tout en cloud managé

Scénario 2 : n8n auto-hébergé

Pour comparaison, un outil SaaS comme Guru, Slite AI ou Glean coûte entre 8 et 25 $ par utilisateur par mois. À 18 utilisateurs, c'est 144 à 450 $/mois. Le pipeline n8n coûte 10 à 15 fois moins cher. Le SBE Council rapporte que 82 % des petites entreprises ont investi dans des outils IA en 2026 — mais combien évaluent le coût réel par rapport à une solution montée en interne ?

Le minimum technique pour auto-héberger n8n : 1 vCPU, 2 Go de RAM, 20 Go de SSD. En pratique, avec l'agent RAG et le stockage des logs, je recommande 2 vCPU et 4 Go de RAM. Un VPS chez Hetzner à cette configuration coûte 7,50 €/mois.

Les 5 pièges que j'ai rencontrés — et comment les contourner

1. Le chunking naïf détruit la qualité des réponses

Déjà raconté plus haut, mais j'insiste : c'est l'erreur numéro un. Le Recursive Character Splitter de n8n, avec les séparateurs \n\n puis \n puis ., produit des résultats nettement meilleurs qu'un découpage à taille fixe. Testez toujours avec 10 questions connues avant de déployer.

2. Les Google Sheets ingérés en brut polluent la base

Un tableau Google Sheets exporté en texte donne une bouillie de cellules séparées par des tabulations. Le chatbot ne comprend rien. Solution : soit ignorez les Sheets (filtre par MIME type dans le trigger), soit convertissez-les en CSV propre via un nœud Code avant le splitting.

3. La mémoire de conversation qui explose le contexte

J'avais configuré une Window Buffer Memory de 20 messages. Résultat : après 10 échanges dans un thread, le contexte envoyé au LLM dépassait 8 000 tokens — dont 6 000 tokens de conversation précédente et seulement 2 000 tokens de documents RAG. Le modèle répondait à partir de ses réponses précédentes plutôt que des docs. J'ai réduit à 5 messages. La qualité a remonté immédiatement.

4. L'absence de logging rend le debug impossible

Quand le chatbot répond mal, vous devez savoir : quels chunks ont été récupérés ? Quel score de similarité ? Quel prompt complet a été envoyé au LLM ? Ajoutez un nœud qui log chaque requête et ses chunks dans une table Supabase dédiée. Ça m'a sauvé 3 heures de debug aveugle.

5. Les gros fichiers PDF mal parsés

Certains PDF (rapports annuels, plaquettes) contiennent des images, des tableaux et des mises en page complexes. Le parsing natif de n8n via le nœud Extract from File produit parfois du texte illisible. Pour les PDF critiques, j'ai ajouté un appel à l'API Mistral avec le mode document, qui parse bien mieux les mises en page complexes — mais ça ajoute un coût et de la latence.

Garder la base RAG à jour : le workflow de synchronisation

Un chatbot RAG avec des docs obsolètes est pire qu'inutile : il donne des réponses fausses avec assurance. La synchronisation est non négociable.

Le Google Drive Trigger surveille votre dossier en continu. Mais que se passe-t-il quand un fichier est supprimé ? Le trigger ne capture pas les suppressions par défaut. J'ai ajouté un workflow planifié (cron toutes les 24h) qui compare les file_id en base avec ceux du dossier Drive via l'API Google. Les orphelins sont supprimés.

Deuxième point : quand un document est modifié, le workflow d'ingestion supprime les anciens chunks (par file_id) puis réinsère les nouveaux. Ça garantit qu'il n'y a jamais deux versions du même doc dans la base.

Des entreprises comme Delivery Hero rapportent 200 heures économisées par mois grâce à l'automatisation de ce type de workflows dans n8n. L'investissement initial de 3-4 heures de setup se rembourse en quelques jours.

Aller plus loin : 3 améliorations à envisager dans un second temps

Le pipeline de base fonctionne. Si vous voulez aller plus loin après quelques semaines d'usage, voici ce que je prévois d'ajouter :

Multi-query RAG. Au lieu de chercher les chunks avec la question brute de l'utilisateur, un nœud intermédiaire reformule la question en 3 variantes avant de chercher. Ça améliore le recall de 15 à 30 % sur les questions ambiguës. n8n propose un template dédié.

Feedback loop. Ajoutez des boutons 👍/👎 sur chaque réponse Slack. Stockez les feedbacks dans Supabase. Après 100 réponses notées, vous identifiez les documents mal indexés et les questions qui posent problème.

Droits d'accès par équipe. Stockez le nom de l'équipe (dev, marketing, RH) dans les métadonnées des chunks. Filtrez les résultats selon l'équipe de l'utilisateur. Un développeur ne devrait pas tomber sur les fiches de paie, et un commercial n'a pas besoin des runbooks de prod.

Pour qui ce montage vaut le coup — notre verdict

Après un mois d'usage avec 18 personnes, le chatbot traite 85 % des questions documentaires sans intervention humaine. Le temps moyen de recherche d'information est passé de 12 minutes à 30 secondes. Trois personnes qui posaient des questions récurrentes aux seniors ne le font plus — elles interrogent le bot.

Ce pipeline est fait pour vous si :

• Votre équipe passe plus de 30 minutes par jour à chercher des docs internes
• Vous avez 50 à 2 000 documents texte structurés (procédures, specs, FAQ, guides)
• Vous utilisez déjà Google Drive ou OneDrive
• Vous êtes à l'aise avec un outil no-code type n8n ou Make (ou prêt à y passer 2h)

Ce pipeline n'est PAS fait pour vous si :

• Vos documents sont principalement des images ou des scans non OCR-isés
• Vous avez besoin de réponses certifiées (médical, juridique contraignant) — le RAG réduit les hallucinations, il ne les élimine pas
• Votre base documentaire change plusieurs fois par heure (le trigger Google Drive n'est pas temps réel, il poll toutes les quelques minutes)
• Vous n'avez que 10 documents — un simple projet Claude avec upload de fichiers suffit

Le RAG ne remplace pas une GED. Il rend vos docs existants interrogeables par l'équipe, sans migration, sans restructuration. C'est sa force — et sa limite.