RAG sur SharePoint avec n8n : interrogez vos documents Microsoft 365

Des années de comptes rendus, de procédures, de contrats et de présentations dorment dans SharePoint et OneDrive. La recherche native retrouve un fichier quand on connaît déjà son nom ; pour la question « quelle est notre politique de remboursement des frais de déplacement ? », personne ne sait dans quel site, quelle bibliothèque, quelle version chercher. C'est exactement le problème que résout le RAG (retrieval-augmented generation), dont le principe est posé par l'article fondateur de Patrick Lewis et al. présenté à NeurIPS en 2020 (« Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks », voir sur Google Scholar) : ancrer la génération d'un modèle de langage dans des documents récupérés produit des réponses plus factuelles et plus spécifiques qu'un modèle seul — et permet de citer la source. Voici comment construire cet assistant sur votre tenant Microsoft 365 avec n8n.

Architecture : deux workflows

Comme pour un RAG sur Google Drive, le système se découpe en deux workflows indépendants :

1. Indexation : parcourir les bibliothèques SharePoint via Microsoft Graph, télécharger les fichiers, extraire le texte, le découper, le vectoriser, l'insérer dans une base vectorielle avec ses métadonnées.
2. Interrogation : un chatbot qui cherche dans cette base et répond avec un lien vers le document source.

INDEXATION (Schedule Trigger)
Graph: /sites/{site-id}/drives
  → /drives/{drive-id}/root/children (parcours récursif)
  → /drives/{drive-id}/items/{id}/content (téléchargement)
  → Extract from File (PDF, DOCX)
  → Chunking → Embeddings → Vector Store (Supabase pgvector / Qdrant)

INTERROGATION
Chat Trigger → AI Agent ←→ Vector Store (outil de retrieval)
  → réponse + URL SharePoint du document cité

La séparation compte : l'indexation tourne la nuit sur un planning, l'interrogation répond en continu ; chacun évolue sans casser l'autre.

Accéder à SharePoint : app registration et Microsoft Graph

Tout passe par l'API Microsoft Graph, appelée depuis n8n avec le node HTTP Request et un credential OAuth2 Microsoft. La préparation se fait dans Azure :

1. Dans Entra ID (ex-Azure AD), créez une app registration et notez le client_id, le tenant_id, puis générez un client_secret.
2. Dans API permissions, ajoutez Sites.Read.All ou Files.Read.All en application permissions (pas delegated), puis faites accorder le consentement administrateur.
3. Le flux client credentials est le bon choix ici : votre workflow d'indexation est un service qui tourne la nuit, pas un utilisateur devant un écran. n8n obtient un token en son propre nom, sans dépendre de la session d'un compte humain qui expire ou part de l'entreprise. C'est le même principe que pour automatiser Outlook et Microsoft 365 avec n8n, où la configuration Azure est détaillée pas à pas.

Le token s'obtient sur https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token avec le scope https://graph.microsoft.com/.default ; le credential OAuth2 API de n8n en mode client credentials gère le renouvellement automatiquement.

Les endpoints Graph du pipeline d'indexation

Trois appels suffisent à parcourir une bibliothèque documentaire. D'abord, identifier le site et ses drives (chaque bibliothèque de documents SharePoint est un « drive » au sens Graph — OneDrive utilise la même API) :

GET https://graph.microsoft.com/v1.0/sites/{hostname}:/sites/{site-name}
→ renvoie le site-id

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives
→ liste les bibliothèques (drive-id de chacune)

Ensuite, lister les fichiers d'un drive :

GET https://graph.microsoft.com/v1.0/drives/{drive-id}/root/children
→ fichiers et dossiers à la racine ; pour un sous-dossier :
GET https://graph.microsoft.com/v1.0/drives/{drive-id}/items/{folder-id}/children

Chaque élément renvoyé porte name, lastModifiedDateTime, createdBy, parentReference.path et surtout webUrl — l'URL SharePoint du document, à conserver précieusement pour les citations. Les dossiers ont une propriété folder : un petit sous-workflow récursif (le node HTTP Request dans une boucle sur les éléments de type dossier) parcourt toute l'arborescence. Pensez à la pagination : Graph renvoie les pages via @odata.nextLink.

Enfin, télécharger le contenu binaire :

GET https://graph.microsoft.com/v1.0/drives/{drive-id}/items/{item-id}/content
→ le fichier lui-même (302 suivi automatiquement par HTTP Request, réglé sur « File » en réponse)

Filtrez en amont sur l'extension : PDF, DOCX, PPTX et TXT valent l'indexation ; images, vidéos et archives n'apportent que du bruit.

Extraction, chunking, insertion

Le binaire téléchargé passe dans Extract from File : opération PDF pour les PDF, et le texte des DOCX s'extrait tout aussi directement. Les PDF scannés sans couche texte nécessitent un OCR en amont — Graph ne fait pas ce travail pour vous.

Le texte extrait suit ensuite le pipeline RAG classique : découpage en chunks de 500 à 1 000 tokens avec chevauchement (les règles complètes sont dans notre guide du chunking de documents pour le RAG), vectorisation avec le modèle retenu selon notre comparatif des modèles d'embeddings, puis insertion via un node Vector Store — Supabase pgvector si vous préférez rester en SQL (configuration Supabase ici), Qdrant en solution dédiée.

Les métadonnées de chaque chunk font la différence entre un index et un bon index. Stockez au minimum :

• item_id et drive_id Graph (clé de réindexation) ;
• site et path (le chemin parentReference.path, pour filtrer par bibliothèque) ;
• author (createdBy.user.displayName) et last_modified ;
• web_url — c'est lui qui transformera chaque réponse du chatbot en réponse sourcée, avec un lien cliquable vers le document dans SharePoint.

Synchronisation incrémentale

Réindexer tout un tenant chaque nuit ne tient pas la route au-delà de quelques centaines de fichiers. Deux mécanismes, du plus simple au plus robuste :

• Filtre sur lastModifiedDateTime : un Schedule Trigger nocturne liste les fichiers et ne traite que ceux modifiés depuis la dernière exécution (date stockée dans une variable de workflow ou une table). Simple, mais ne détecte pas les suppressions.
• Delta query Graph : l'endpoint GET /drives/{drive-id}/root/delta renvoie tous les changements — créations, modifications et suppressions — depuis le dernier appel, matérialisé par un jeton @odata.deltaLink à conserver entre deux exécutions. C'est le mécanisme conçu exactement pour ce cas.

Dans les deux cas, la règle d'or : à chaque fichier modifié, supprimez d'abord tous les vecteurs portant son item_id, puis réinsérez les nouveaux chunks — sinon les versions s'accumulent et le chatbot cite des procédures obsolètes. Ce cycle de vie complet de l'index (mises à jour, suppressions, réconciliation) est traité en détail dans notre guide pour maintenir un index RAG à jour.

Le workflow d'interrogation

La partie aval est un RAG standard : un Chat Trigger ouvre l'interface de conversation, un AI Agent reçoit la question, et le node Vector Store branché en outil de l'agent effectue le retrieval. Dans le prompt système de l'agent, imposez deux règles : ne répondre qu'à partir des passages récupérés, et terminer chaque réponse par la ou les sources — le web_url stocké en métadonnée, formaté en lien Markdown vers le document SharePoint. L'utilisateur obtient la réponse et le moyen de la vérifier en un clic, ce qui change tout pour l'adoption en interne.

Si la pertinence plafonne sur les termes exacts — références produits, noms de projets, acronymes internes dont SharePoint regorge — la recherche hybride (vecteurs + mots-clés) est le premier levier à activer.

Attention : l'index ignore les permissions SharePoint

Le point de gouvernance qui doit être tranché avant la mise en production : votre app registration lit tout ce que ses permissions couvrent, et l'index vectoriel ne conserve aucune trace des ACL SharePoint. Un document confidentiel RH indexé devient lisible par tous les utilisateurs du chatbot, y compris ceux qui n'ont aucun accès au site d'origine.

La parade : indexer par périmètre. Un index (ou une collection) par population d'utilisateurs — un pour les documents ouverts à toute l'entreprise, un pour la direction, un par équipe si nécessaire — et un chatbot qui n'interroge que les index auxquels son audience a droit. À défaut, stockez le site source en métadonnée et filtrez à la requête selon l'utilisateur. Sans ce garde-fou, votre assistant documentaire est une fuite de données interne particulièrement efficace.

Le même schéma s'applique d'ailleurs à vos autres sources : le pipeline de cet article se transpose presque tel quel à Notion ou à Google Drive — seule la couche d'accès aux fichiers change, le cœur RAG reste identique.