Un RAG sur votre propre site web avec n8n, Firecrawl et Supabase : le chatbot qui répond à partir de vos pages

Une PME avec un site correct — pages services, documentation produit, FAQ, blog — a déjà rédigé les réponses à la majorité des questions que reçoivent son support et ses commerciaux. Le problème n'est pas le contenu, c'est l'accès : personne ne lit quarante pages avant d'écrire un email. Un chatbot RAG branché sur le contenu du site inverse la charge : le visiteur pose sa question, l'assistant retrouve les passages pertinents dans vos pages et répond en les citant. Support de premier niveau, préqualification des demandes entrantes, aide interne pour les nouveaux arrivants : même mécanique, même index.

Nous avons déjà couvert les briques une par une — connecter Firecrawl à n8n pour le scraping, le RAG avec Supabase pgvector pour le stockage vectoriel. Ce guide les assemble en un cas d'usage complet et spécifique : indexer son propre site et le maintenir à jour, ce qui pose des questions que l'ingestion de PDF ne pose pas — périmètre du crawl, upsert par URL, détection du contenu inchangé.

Pourquoi crawler son site plutôt qu'exporter le CMS

Le réflexe initial est souvent d'aller chercher le contenu à la source : export WordPress, requête sur la base, API du headless CMS. C'est presque toujours le mauvais chemin, pour trois raisons :

• Le site publié est la source de vérité. C'est le contenu réellement en ligne, relu, maintenu, celui que vos visiteurs voient. Un export CMS peut contenir des brouillons, des révisions, des champs techniques — et rater ce qu'un plugin ou un builder assemble au rendu.
• Le crawl est indépendant du format interne. Peu importe que le site tourne sur WordPress, Webflow, un générateur statique ou un mélange des trois : Firecrawl renvoie le même markdown propre pour toutes les pages. Changez de CMS l'an prochain, le pipeline d'ingestion ne bouge pas d'une ligne.
• L'URL vient gratuitement. Chaque page crawlée arrive avec son URL publique — exactement la métadonnée dont le chatbot aura besoin pour citer ses sources. Un export CMS vous obligerait à la reconstruire.

L'export direct garde un intérêt dans un cas précis : du contenu non publié (procédures internes, base de connaissances privée) qui n'a pas vocation à être sur le site. Pour tout ce qui est en ligne, crawlez.

Étape 1 — Crawler le site avec Firecrawl

L'opération Crawl de Firecrawl parcourt le site en suivant les liens et renvoie chaque page en markdown débarrassé du gabarit — menus, pieds de page, bandeaux cookies. La connexion (node natif sur n8n Cloud, node communautaire en self-hosted, ou HTTP Request direct avec vos credentials) est détaillée dans notre guide Firecrawl ; concentrons-nous ici sur le paramétrage propre à ce cas d'usage.

Deux réglages comptent plus que tous les autres :

• Le périmètre. Le crawl reste par construction dans le domaine de départ, mais restreignez-le davantage avec les motifs d'inclusion et d'exclusion : inutile d'indexer les mentions légales, la politique de confidentialité, les pages panier ou compte client, les archives paginées du blog. Chaque page inutile indexée est du bruit dans les résultats de recherche et des crédits consommés. Une configuration type ressemble à ceci :

{
  "url": "https://www.votresite.fr",
  "includePaths": ["/services/.*", "/docs/.*", "/blog/.*", "/faq.*"],
  "excludePaths": ["/mentions-legales.*", "/panier.*", "/mon-compte.*", "/blog/page/.*"],
  "scrapeOptions": { "formats": ["markdown"] }
}

• L'asynchronisme. Un crawl est un job asynchrone : on le lance, puis on interroge son statut jusqu'à complétion avant de récupérer les pages. Dans n8n, c'est une boucle Wait + vérification du statut, ou l'opération Crawl Status du node.

À la sortie, chaque item porte le markdown de la page et ses métadonnées — dont l'URL et le titre. Ne les perdez pas : tout le reste du pipeline en dépend.

Étape 2 — Chunker par sections, pas en blocs arbitraires

Le markdown de Firecrawl a un avantage décisif sur du texte brut : il est déjà structuré par titres. Exploitez-le. Plutôt qu'un découpage aveugle tous les 1000 caractères, découpez par sections — chaque ## ou ### ouvre un chunk — en ne re-découpant que les sections trop longues. Une question de visiteur porte presque toujours sur un sujet que le rédacteur a déjà isolé sous un titre : un chunk qui épouse la section a toutes les chances de contenir la réponse entière, là où un bloc arbitraire la coupe en deux. Notre guide du chunking compare les stratégies en détail.

Le point non négociable : chaque chunk doit emporter ses métadonnées — l'URL de la page, le titre de la page, et le titre de la section d'où il vient. C'est ce qui permettra au chatbot de citer « la page Tarifs, section Engagement » avec un lien cliquable, au lieu d'une réponse invérifiable. Dans un node Code, la structure cible par chunk :

{
  "chunk": "Texte de la section...",
  "metadata": {
    "url": "https://www.votresite.fr/services/maintenance",
    "titre": "Maintenance applicative",
    "section": "Délais d'intervention"
  }
}

Étape 3 — Embeddings et stockage dans Supabase pgvector

La mécanique embeddings + pgvector est celle de notre guide RAG Supabase ; seule la table change légèrement pour matérialiser l'URL en colonne — vous allez filtrer et supprimer par URL à chaque mise à jour, autant que ce soit une colonne indexée plutôt qu'un champ enfoui dans le JSON :

create extension if not exists vector;

create table documents (
  id bigserial primary key,
  url text not null,
  chunk text,
  embedding vector(1536),
  metadata jsonb
);

-- Index pour les suppressions/upserts par URL
create index idx_documents_url on documents (url);

-- Index vectoriel (utile au-delà de ~10 000 chunks)
create index on documents using hnsw (embedding vector_cosine_ops);

Le workflow d'ingestion enchaîne : chunks → node d'embeddings (le même modèle qu'à l'interrogation, toujours) → insertion dans documents, avec url extraite des métadonnées et le reste conservé dans metadata. Pour un site de PME — quelques dizaines à quelques centaines de pages — l'ingestion complète se compte en minutes.

Étape 4 — Maintenir l'index à jour : re-crawl, upsert par URL, hash

Un site vit : pages modifiées, articles publiés, offres retirées. Un index figé devient faux silencieusement — le chatbot citera un tarif obsolète avec aplomb. La stratégie qui fonctionne, détaillée dans notre guide mettre à jour un index RAG, tient en trois principes :

1. Re-crawl planifié. Un Schedule Trigger hebdomadaire relance le même crawl. Pour la plupart des sites de PME, l'hebdomadaire suffit largement ; passez au quotidien seulement si le contenu bouge vraiment chaque jour.
2. Upsert par URL, pas par chunk. Pour chaque URL re-crawlée : supprimer tous ses anciens chunks, puis insérer les nouveaux. Tenter de mettre à jour chunk par chunk est un piège — dès qu'un paragraphe bouge, le découpage entier de la page se décale. La suppression-réinsertion par URL est atomique à l'échelle qui compte (la page) et triviale grâce à la colonne url :

delete from documents where url = $1;
-- puis insertion des nouveaux chunks de cette URL

3. Hash pour détecter l'inchangé. La majorité des pages ne changent pas d'une semaine à l'autre. Stockez un hash du markdown de chaque page (dans une petite table pages_hash ou dans les metadata), comparez-le au hash du nouveau crawl, et ne ré-embeddez que les pages dont le hash a changé. Sur un site de 200 pages dont 5 bougent par semaine, c'est la différence entre 200 et 5 passages par l'API d'embeddings — chaque semaine.

Étape 5 — Interroger : agent, citations, recherche hybride

Côté conversation, l'architecture est celle du guide Supabase : un Chat Trigger, puis un AI Agent équipé du vector store en outil de recherche (ou une chaîne Question and Answer pour une FAQ pure, plus simple et plus déterministe). La spécificité du RAG « site web » est dans le message système : les sources sont des URLs publiques, exigez-les.

Tu réponds uniquement à partir du contenu du site fourni par l'outil de recherche.
Termine chaque réponse par "Sources :" suivi des metadata.url des passages utilisés.
Si le site ne couvre pas la question, dis-le et propose de contacter l'équipe,
au lieu d'inventer.

C'est exactement le principe validé par l'article fondateur du RAG : Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS 2020 — voir sur Google Scholar), montrent qu'associer un générateur à un index de passages récupérables produit des réponses plus factuelles — et actualisables en changeant l'index, sans toucher au modèle. C'est précisément ce que fait votre re-crawl hebdomadaire : la connaissance du chatbot se met à jour avec le site, sans réentraîner quoi que ce soit.

Un raffinement vaut la peine dès que vos visiteurs cherchent des termes exacts — références produit, noms propres, codes d'erreur : la recherche vectorielle pure peut rater « GX-450 » au profit de passages sémantiquement proches mais hors sujet. La recherche hybride (vectoriel + plein texte) corrige cela ; notre guide de la recherche hybride détaille sa mise en place sur la même table Supabase. Et avant d'annoncer le chatbot en interne ou aux clients, passez-le au banc d'essai avec un jeu de questions dont vous connaissez les réponses — notre guide pour évaluer la qualité d'un RAG donne la méthode.

Étape 6 — L'intégrer sur le site

Reste à mettre le chatbot devant les visiteurs. Le Chat Trigger de n8n peut être exposé publiquement et embarqué sur le site via le widget de chat — apparence, textes d'accueil, position sur la page : tout est couvert dans notre guide du widget de chat IA sur votre site. Pour un usage interne (aide aux nouveaux arrivants, support commercial), l'interface de chat intégrée à n8n suffit, sans rien exposer publiquement.

Pièges fréquents

• Crawler sans exclusions : mentions légales, pages panier, archives paginées finissent dans l'index, polluent les résultats et consomment des crédits pour rien.
• Perdre l'URL en route : un chunking qui ne propage pas les métadonnées produit un chatbot incapable de citer ses sources — et donc invérifiable.
• Découper en blocs arbitraires un markdown déjà structuré par titres : les réponses se retrouvent coupées en deux chunks, la pertinence chute.
• Réindexer tout le site à chaque mise à jour au lieu d'un upsert par URL avec détection par hash : coût d'embeddings multiplié pour rien.
• Mettre à jour chunk par chunk : dès qu'un paragraphe change, le découpage de toute la page se décale ; supprimez et réinsérez par URL.
• Oublier la consigne anti-hallucination dans le message système : un chatbot public qui invente une réponse sur vos tarifs coûte plus cher que pas de chatbot du tout.
• Lancer sans évaluer : testez avec des questions couvertes et non couvertes par le site avant d'ouvrir aux visiteurs.

En résumé

Le pipeline complet tient en deux workflows n8n : ingestion (crawl Firecrawl périmétré → chunking par sections avec URL et titre en métadonnées → embeddings → Supabase pgvector) et conversation (Chat Trigger → agent avec recherche vectorielle, ou hybride, et citations des URLs), plus un troisième pour la mise à jour hebdomadaire par upsert et hash. Chaque brique est simple ; c'est l'assemblage — périmètre, métadonnées, stratégie de mise à jour — qui fait la différence entre un gadget et un assistant qu'on peut mettre devant des clients. Pour partir d'une base déjà câblée plutôt que d'une page blanche, le Pack Assistant RAG (119 €) fournit les workflows d'ingestion, de vectorisation et de chatbot avec citations prêts à importer : il ne reste qu'à brancher le crawl Firecrawl en entrée et à coller vos clés.