Indexer Google Drive dans un RAG avec n8n : vos documents internes enfin interrogeables

La documentation interne d'une PME vit rarement dans un outil dédié : elle s'accumule dans Google Drive — procédures, comptes rendus, contrats, offres commerciales. Résultat : l'information existe, mais personne ne la retrouve. Le RAG (retrieval-augmented generation) répond précisément à ce problème, et son principe est posé par l'article fondateur de Lewis et al. présenté à NeurIPS en 2020 (« Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks », voir sur Google Scholar) : plutôt que d'espérer qu'un modèle « sache », on récupère les passages pertinents d'une base documentaire et on les lui fournit au moment de répondre — ce qui améliore la factualité et permet de citer ses sources. Reste à alimenter cette base. Voici le pipeline n8n complet pour indexer un Drive et le garder à jour.

Architecture du pipeline

1. Détection : un node Google Drive Trigger surveille le dossier cible (création et modification de fichiers).
2. Téléchargement et extraction : le fichier est téléchargé, les formats Google (Docs, Sheets) sont exportés en texte, les PDF et DOCX passent par Extract From File.
3. Chunking : le texte est découpé en chunks avec chevauchement.
4. Embeddings et insertion : chaque chunk est vectorisé puis inséré dans la base vectorielle avec ses métadonnées (ID du fichier Drive, nom, date de modification, dossier).
5. Réindexation : à la modification d'un fichier, ses anciens vecteurs sont supprimés avant insertion des nouveaux.

Côté base vectorielle, les options habituelles s'appliquent : Supabase pgvector si vous voulez rester en SQL, Qdrant ou Pinecone en solution dédiée. Les exemples ci-dessous supposent Supabase, comme notre workflow gratuit d'ingestion de PDF dans Supabase pgvector, dont ce pipeline est l'extension naturelle.

Étape 1 : surveiller le bon périmètre

Le Google Drive Trigger (crédentiel OAuth2 — configuration pas à pas ici) se règle sur un dossier précis et un type d'événement : File Created et File Updated. Deux précisions d'expérience :

• Le trigger fonctionne par sondage : réglez l'intervalle selon la fraîcheur requise (toutes les 15 minutes suffit pour de la documentation interne).
• Pour une arborescence avec sous-dossiers, doublez le trigger d'un workflow planifié (Schedule Trigger) qui liste les fichiers modifiés depuis la dernière exécution et rattrape ce que le sondage aurait manqué — le pattern classique de réconciliation.

Filtrez d'emblée les types de fichiers : indexer les images, vidéos et archives n'apporte que du bruit. Un node IF sur le MIME type garde Docs, PDF, DOCX et TXT.

Étape 2 : télécharger et extraire le texte

L'opération Download du node Google Drive gère la subtilité des formats Google : un Google Doc n'est pas un fichier mais un document en ligne — l'option de conversion l'exporte en texte brut ou PDF au téléchargement. Les fichiers classiques (PDF natifs, DOCX, TXT) passent ensuite par Extract From File. Les PDF scannés nécessitent un OCR en amont, et les tableurs méritent un traitement dédié ligne à ligne plutôt qu'une extraction brute — voir notre guide des fichiers Excel et CSV dans n8n.

Étape 3 : chunking et embeddings

Le découpage suit les règles détaillées dans notre guide du chunking de documents pour le RAG : chunks de 500 à 1 000 tokens, chevauchement de 10-15 %, découpe sur les frontières sémantiques. Dans n8n, le Default Data Loader et le Recursive Character Text Splitter branchés sur le node Vector Store font ce travail nativement. Pour le modèle d'embeddings, notre comparatif des modèles d'embeddings s'applique — l'essentiel étant de ne jamais changer de modèle sans réindexer tout le corpus.

Le point décisif pour la suite : les métadonnées. Stockez avec chaque chunk l'ID du fichier Drive, son nom, son URL, sa date de modification et son dossier parent. C'est ce qui permet la réindexation propre, les réponses avec citations cliquables, et le filtrage par métadonnées (par exemple, restreindre une recherche aux procédures RH).

Étape 4 : la réindexation, le vrai sujet

L'erreur classique des pipelines Drive → RAG n'est pas à l'indexation initiale, mais à la mise à jour : un document modifié est réinséré sans suppression des anciens vecteurs, et la base accumule des versions contradictoires — le chatbot cite alors la procédure de 2024 à côté de celle de 2026. La séquence correcte à chaque événement File Updated :

1. Delete dans la base vectorielle de tous les vecteurs dont la métadonnée drive_file_id correspond au fichier (une requête SQL directe avec le node Postgres sur Supabase).
2. Réextraction, rechunking, réinsertion.
3. Journalisation (fichier, nombre de chunks, date) dans une Data Table — votre tableau de bord d'indexation.

Traitez aussi la suppression : un fichier retiré du Drive doit disparaître de l'index, sinon le RAG continue de citer un document que l'organisation a jugé bon de supprimer. Le workflow de réconciliation planifié de l'étape 1 est l'endroit naturel pour cette détection.

Interroger : la partie déjà connue

Une fois le Drive indexé, l'interrogation est un RAG standard : retrieval, génération avec citations, et les raffinements habituels — recherche hybride pour les termes exacts (références, noms de produits), reranking si la pertinence plafonne. Le Pack Assistant RAG (119 €) fournit exactement cette moitié aval prête à brancher : chatbot avec citations, API question-réponse et synchronisation Notion — le pipeline Drive de cet article s'y substitue ou s'y ajoute comme source d'ingestion.

Un point de gouvernance pour finir : l'index vectoriel ne connaît pas les permissions Drive. N'indexez que ce que tous les utilisateurs du chatbot peuvent lire, ou portez les droits d'accès en métadonnées et filtrez à la requête. C'est la différence entre un assistant documentaire et une fuite de données interne bien organisée.