Node Confluence natif dans n8n : importer une arborescence de pages entière pour du RAG

Jusqu’ici, brancher n8n sur Confluence pour un pipeline RAG imposait de passer par le node HTTP Request et l’API REST Confluence Cloud : gestion manuelle du jeton API, pagination page par page, et surtout aucun moyen de récupérer une arborescence complète de pages sans coder soi-même la récursion sur les enfants. Notre guide du RAG sur Confluence documentait précisément cette approche, faute d’alternative native. Avec n8n 2.40.0, sorti le 15 septembre 2026, ce n’est plus le cas : un node Confluence natif fait son apparition, avec authentification OAuth2 gérée par n8n et une option qui change concrètement la façon d’ingérer une base de connaissances Confluence pour de la génération augmentée par récupération.

Ce n’est pas un détail cosmétique. Une architecture qui préserve la structure hiérarchique d’un corpus plutôt que de l’aplatir en une liste de fragments améliore la qualité de la récupération : c’est exactement ce que montrent Sarthi et ses co-auteurs (Stanford) dans RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (ICLR 2024), où l’indexation d’un arbre de résumés à plusieurs niveaux d’abstraction surpasse la récupération de fragments courts et isolés sur des tâches nécessitant une compréhension globale du document. Un espace Confluence est justement une arborescence — un dossier de procédures avec ses sous-pages, une base de connaissances produit organisée en chapitres — et un node qui la restitue dans l’ordre du plan plutôt qu’en vrac facilite tout le travail de chunking qui suit.

Ce qui change avec le node natif

Le node Confluence natif expose une quinzaine d’opérations réparties sur quatre ressources : Page (créer, lire, mettre à jour, supprimer, et lister les commentaires de pied de page), Attachment, Search et Space. Pour un usage RAG, ce sont surtout les ressources Page et Search qui comptent : Page pour l’extraction du contenu, Search pour retrouver rapidement les pages pertinentes dans un espace volumineux avant de les indexer.

La différence la plus visible avec l’ancienne approche par HTTP Request tient à l’authentification. Plus besoin de générer un jeton API sur un compte de service et de le stocker en Basic Auth : le node utilise un credential OAuth2 Confluence Cloud, configuré une seule fois. Depuis l’Atlassian Developer Console, on crée une intégration OAuth 2.0, on colle l’URL de redirection fournie par n8n dans le champ callback, on ajoute les scopes Confluence nécessaires à la lecture (et à l’écriture si le workflow doit créer ou mettre à jour des pages), puis on autorise la connexion depuis n8n. Le scope offline_access est demandé automatiquement pour permettre le rafraîchissement du jeton sans repasser par l’écran de connexion à chaque expiration. Dans le node lui-même, le paramètre Site propose ensuite de choisir parmi les sites Confluence accessibles à la connexion, ou de coller directement l’URL du site si plusieurs organisations sont en jeu.

Get Page + Include Descendants : l’arborescence en un seul node

Le vrai changement pour un pipeline d’ingestion se trouve dans l’opération Get de la ressource Page, avec l’option Include Descendants activée. Au lieu de renvoyer uniquement la page demandée, le node parcourt récursivement tous ses descendants — sous-pages, sous-sous-pages, sur toute la profondeur de l’arborescence — et les renvoie en une seule sortie, avec un plafond configurable via Max Pages pour éviter qu’un espace immense n’explose la mémoire d’une exécution.

Ce mécanisme existait déjà à la sortie du node, mais avec deux défauts corrigés seulement dans la version 2.40.0. D’abord un problème d’ordre : les pages sortaient triées selon l’ID interne attribué par Confluence au moment de leur création, pas selon leur position dans l’arbre — un enfant pouvait ainsi apparaître avant son propre parent dans le flux, ce qui compliquait la reconstruction du plan documentaire en aval. Le correctif réordonne désormais les pages selon le parcours réel de l’arborescence, avec la racine systématiquement en tête. Ensuite un problème de budget : les pages en brouillon (non publiées) consommaient un emplacement du quota Max Pages sans jamais apparaître dans la sortie, gaspillant une partie de la limite fixée sur du contenu invisible ; l’espace disponible ne compte désormais que les pages effectivement publiées, tout en continuant de descendre sous un brouillon pour retrouver ses éventuels descendants publiés.

Concrètement, un seul node Confluence configuré sur la page racine d’un espace de documentation, avec Include Descendants activé, remplace ce qui demandait auparavant une boucle Loop Over Items couplée à des appels HTTP Request récursifs sur l’API /child/page.

Adapter un pipeline RAG existant

Si vous avez déjà construit un pipeline suivant l’approche HTTP Request décrite dans notre guide du RAG sur Confluence, rien n’oblige à tout réécrire : la partie qui change est uniquement l’extraction, pas ce qui suit. Le format de sortie du node natif reste du contenu structuré par page (titre, corps, métadonnées _links), donc les étapes de conversion en texte, de découpage en chunks qui respecte les titres de section, de génération d’embeddings et de stockage dans Supabase avec pgvector — décrites dans notre guide RAG avec Supabase — restent identiques. Seule différence à prévoir : le corps de page renvoyé par le node natif peut différer légèrement du format storage brut utilisé par l’ancienne approche HTTP, donc un test sur quelques pages représentatives (avec macros, tableaux, pièces jointes intégrées) avant de lancer une indexation complète évite les mauvaises surprises.

Pour les besoins qui dépassent la simple extraction d’arborescence — une requête CQL combinant plusieurs espaces et des filtres sur des métadonnées personnalisées, par exemple — le node HTTP Request direct sur l’API REST garde son utilité : le node natif simplifie le cas courant, il ne prétend pas couvrir tous les usages avancés.

Bonnes pratiques pour l’ingestion

Quelques points à surveiller en production :

• Dimensionnez Max Pages en connaissance de cause. Un espace de plusieurs milliers de pages peut dépasser une limite fixée trop bas ; mieux vaut segmenter l’ingestion par sous-arborescence (une page racine par équipe ou par produit) que remonter un seul espace entier en une seule exécution.
• Respectez les limites de débit de l’API Confluence Cloud, comme pour tout connecteur Atlassian — le même principe que celui détaillé dans notre article sur le RAG avec Notion s’applique : séquencez plutôt que paralléliser, et activez le retry sur les nodes concernés.
• Prévoyez une synchronisation incrémentale plutôt qu’une réindexation complète à chaque exécution, en filtrant sur la date de dernière modification et en appliquant le même schéma delete-puis-insert que pour les autres sources documentaires, détaillé dans notre guide de mise à jour d’un index RAG.
• Restez sur un compte de service dédié pour le credential OAuth2, avec un accès limité en lecture aux seuls espaces à indexer.

Si vous préférez ne pas assembler ce pipeline pièce par pièce, le Pack Assistant RAG (119 €) fournit l’aval prêt à brancher — ingestion dans Supabase pgvector, chatbot avec citations et API question-réponse — sur lequel connecter l’extraction Confluence, qu’elle passe par le nouveau node natif ou par l’ancienne approche HTTP Request selon vos besoins.

En résumé

• n8n 2.40.0 (15 septembre 2026) introduit un node Confluence natif : credential OAuth2 géré par n8n, ressources Page, Attachment, Search et Space.
• L’option Include Descendants de l’opération Get Page récupère toute une arborescence en un seul node, dans l’ordre réel de l’arbre depuis ce correctif — un point sensible pour la qualité d’un index RAG hiérarchique.
• Les brouillons ne consomment plus inutilement le quota Max Pages, tout en restant traversés pour atteindre leurs descendants publiés.
• L’authentification OAuth2 remplace le jeton API en Basic Auth pour les cas simples ; le HTTP Request direct reste pertinent pour les requêtes CQL avancées.
• Le reste du pipeline RAG (conversion, chunking, embeddings, stockage, synchronisation incrémentale) ne change pas.