Architecture d'un pipeline RAG avec synchronisation Confluence → Azure
Les systèmes RAG (Retrieval-Augmented Generation) ont besoin de données structurées et à jour pour fonctionner efficacement. Or la documentation d'entreprise réside généralement dans Confluence, un système non optimisé pour la consommation par LLM. Et une migration one-shot ne suffit pas : la documentation évolue en continu, creusant un écart entre la base de connaissances migrée et le système RAG qui la consomme.
Pour répondre à ce défi, nous avons conçu un pipeline automatisé qui synchronise quotidiennement Confluence vers Azure selon une architecture en cinq couches : l'ingestion (l'API REST Confluence extrait pages et métadonnées de manière sélective, filtrées par espace et par date de modification), la transformation (conversion du HTML vers un Markdown structuré préservant la hiérarchie sémantique), le storage (Azure Blob Storage reproduit la structure des espaces Confluence), l'indexation (Azure AI Search génère les embeddings vectoriels pour la recherche sémantique) et l'orchestration (Azure Functions pilote l'ensemble via des triggers planifiés). En transverse, Azure Key Vault centralise credentials et secrets pour garantir la conformité aux standards de sécurité enterprise.
Cette architecture élimine la maintenance manuelle tout en garantissant la cohérence entre la documentation source et le système RAG, permettant aux organisations comme Adservio de déployer des capacités d'IA générative fondées sur leurs connaissances propriétaires.
Requirements techniques du pipeline
Un pipeline de synchronisation Confluence-Azure performant repose sur trois exigences que nous rencontrons systématiquement chez Adservio en contexte enterprise : l'efficience opérationnelle, la qualité des transformations et la résilience architecturale.
Synchronisation incrémentale et change detection
Dans un contexte où les bases Confluence contiennent entre 10 000 et 100 000 pages, synchroniser l'intégralité du corpus à chaque run représente plusieurs heures de traitement et des coûts API significatifs. Notre stratégie de change detection repose sur trois mécanismes : le timestamp de dernière modification exposé par l'API Confluence (champ version.when), une table de métadonnées dans Azure Table Storage qui sert de référentiel des versions déjà synchronisées, et un delta sync qui n'extrait, ne transforme et n'indexe que les pages modifiées depuis le dernier run.
Résultat : le temps d'exécution quotidien chute de 2 heures à 5 minutes pour un corpus de 15 000 pages (-95 %), les appels API Confluence passent de 15 000 à 150 en moyenne (-99 %), le coût mensuel Azure Functions de 75 à 15 EUR (-80 %), et la fenêtre de maintenance de 2-3 heures à 5-10 minutes (-96 %), tout en maintenant la fraîcheur des données pour les systèmes RAG en aval.
Transformation HTML vers Markdown
Le HTML natif de Confluence contient du markup de présentation (classes CSS, attributs de layout, structures de navigation) qui dilue le signal sémantique pour les LLM et génère un overhead de 40 à 60 % de tokens par rapport au Markdown pur, sans valeur informative additionnelle. Notre pipeline de transformation enchaîne cinq étapes : parsing HTML avec BeautifulSoup4, extraction des structures porteuses de sens (titres hiérarchiques, listes, blocs de code), suppression des macros propriétaires Confluence qui ne s'exportent pas correctement, conversion Markdown via html2text, puis post-processing (normalisation des espaces, validation structurelle).
Cette transformation réduit de 45 % la taille des embeddings vectoriels tout en améliorant de 23 % le recall@5 dans nos benchmarks RAG internes : un contenu plus compact et structuré produit une meilleure précision de récupération.
Architecture serverless avec auto-scaling
L'architecture Azure Functions repose sur quatre piliers : un Consumption Plan facturé à la milliseconde d'exécution (aucun coût fixe en période d'inactivité), un Timer Trigger planifié quotidiennement à 2 h du matin UTC pour épargner les systèmes source, un timeout adaptatif de 10 minutes par fonction avec chunking des batches volumineux, et une retry policy en exponential backoff limitée à 3 tentatives pour absorber les défaillances transitoires. Elle délivre un débit de 50 pages par minute, un cold start de 8 secondes pour le runtime Python, une disponibilité de 99,95 % (SLA Azure) et un coût mensuel d'environ 15 EUR pour 15 000 pages synchronisées quotidiennement.
Migration sélective par espace
Plutôt que de migrer des ensembles entiers, le pipeline permet la migration sélective des seuls espaces pertinents vers Azure Blob Storage, selon trois impératifs : la pertinence contextuelle (un assistant commercial n'a pas besoin des runbooks d'engineering ; filtrer par espace augmente le signal utile pour chaque persona), la gouvernance (les espaces sensibles, données RH, stratégie commerciale, propriété intellectuelle, ne doivent jamais alimenter certains modèles, en conformité RGPD) et l'optimisation économique (pourquoi payer pour stocker et indexer des données qui ne seront jamais interrogées ?).
Concrètement, une migration complète de 50 espaces (500 Go) coûte environ 250 EUR par mois. Une migration limitée aux 20 espaces pertinents (200 Go) ramène le coût à 100 EUR par mois tout en améliorant le recall de 15 %. Une migration ciblée par persona (3 à 5 espaces, environ 50 Go et 25 EUR par persona) pousse le gain de recall à 25 % : une sélection plus fine améliore simultanément le coût et la pertinence des réponses.
La valeur business d'une base de connaissances IA-ready
La migration n'est qu'une fondation technique : la vraie valeur vient de ce que l'on construit au-dessus. Premier levier, la découverte de connaissances accélérée : en enrichissant le contenu extrait avec de la summarization, des mots-clés et des tags sémantiques, nous avons observé chez nos clients des réductions de 60 à 70 % du temps de recherche d'information.
Deuxième levier, la recherche d'entreprise plus intelligente : avec les embeddings d'Azure AI Search, les utilisateurs posent des questions en langage naturel ("Quelle est notre politique de remboursement pour les projets internationaux ?") au lieu de deviner des mots-clés, et obtiennent directement les réponses les plus pertinentes plutôt que des dizaines de résultats à trier. Les mises à jour incrémentales évitent par ailleurs le phénomène de "documentation périmée" qui mine la confiance des équipes dans les systèmes internes.
Assistants IA spécialisés et onboarding
Avec une base propre et structurée, on construit des assistants spécialisés à périmètre ciblé : un assistant RH pour les politiques d'entreprise, un assistant technique adossé aux runbooks, un assistant commercial pour l'information produit en cours d'appel. Ancrés dans les connaissances propriétaires via RAG, ils réduisent les hallucinations de 80 à 95 % par rapport aux LLM génériques. Pour l'onboarding, un assistant alimenté par la base migrée répond instantanément aux questions récurrentes : les organisations équipées réduisent le temps de ramp-up des nouveaux employés de 30 à 40 % (de 8 à 5 semaines en moyenne).
La centralisation débloque enfin des analyses jusque-là impossibles : quels sujets sont les mieux documentés, où se trouvent les gaps de connaissances critiques, quels documents sont obsolètes ou peu utilisés, autant d'insights qui guident l'effort de documentation et d'amélioration continue.
Enseignements clés
Le déploiement de ce pipeline chez plusieurs clients d'Adservio a produit trois enseignements majeurs, sur les dimensions techniques, sécuritaires et de qualité des données.
Utiliser Markdown pour la documentation : lisible par les humains, versionnable dans Git et parsable sans ambiguïté par les machines, il préserve la hiérarchie d'information (titres, listes, blocs de code) tout en restant compact. Là où le HTML brut (environ 15 Ko par page) noie les LLM dans le bruit de présentation et où le PDF n'est ni parsable ni versionnable, le Markdown (environ 8 Ko) combine lisibilité humaine, parsing LLM optimal et versionning Git sans friction.
Sécuriser les échanges : la connexion à Confluence par certificats SSL chiffre les échanges end-to-end, un prérequis de conformité dans les environnements régulés (RGPD, HIPAA, PCI-DSS). Nous recommandons une rotation des certificats au moins tous les 90 jours et un monitoring actif de leur expiration via des alertes automatisées.
Capturer uniquement les données pertinentes : filtrer agressivement les contenus hors sujet réduit les coûts de stockage de 40 à 60 % tout en améliorant la qualité des réponses IA de 15 à 25 %. Plus le modèle reçoit de données non pertinentes, plus il risque de générer des réponses confuses : la curation des données est un investissement qui paie, sur l'expérience utilisateur comme sur l'efficience économique.
L'importance de la gouvernance dans les pipelines IA
La gouvernance est un pilier fréquemment sous-estimé des pipelines de connaissances IA. Chez Adservio, nous insistons : elle doit être intégrée dès la conception, pas ajoutée après coup comme une rustine réglementaire.
Traçabilité et audit : chaque opération est loggée de manière structurée, quelle page a été extraite, quand (timestamp UTC), par quelle identité managée, quelles transformations ont été appliquées et vers quel chemin blob. Dans les secteurs régulés comme la finance ou la santé (MiFID II, HIPAA), démontrer la data lineage complète est une exigence légale ; nos logs JSON s'intègrent aux SIEM comme Splunk ou Azure Sentinel, avec rétention configurable.
Versioning et rollback : chaque exécution du pipeline crée un point de restauration dans Azure Blob Storage, avec lifecycle policy pour maîtriser les coûts. Une corruption lors de la transformation se restaure en 5 minutes par fallback automatique, une suppression accidentelle en 10 minutes grâce à une rétention de 30 jours, et une défaillance régionale d'Azure en 30 minutes via la géo-redondance, sans perte de données dans les trois cas.
Contrôle d'accès granulaire : un document restreint à une équipe dans Confluence (Sales, Engineering, Executive) doit le rester après migration. Le pipeline synchronise les ACL vers Azure via des metadata tags et des policies IAM, pour que les systèmes RAG en aval respectent les mêmes restrictions.
Conclusion
Migrer du contenu Confluence vers Azure Blob Storage exige une planification minutieuse couvrant les dimensions techniques, sécuritaires et de gouvernance. L'architecture serverless Azure Functions s'est avérée idéale pour ce cas d'usage : scaling pay-per-execution, maintenance réduite, et synchronisation nocturne automatique qui garantit aux équipes de travailler toujours sur les dernières données de Confluence.
Ce pipeline n'est pas un projet ponctuel avec une date de fin, mais une infrastructure critique qui doit évoluer avec les modèles IA (nouveaux modèles d'embedding, contextes plus longs, RAG agentique) pour préserver l'avantage compétitif et maximiser le retour sur investissement.
En synthèse, sur la moyenne de nos clients Adservio : le temps moyen pour trouver une information passe de 15 à 6 minutes (-60 %), les dépenses d'infrastructure mensuelles baissent de 80 % par rapport à une synchronisation complète, le recall@5 progresse de 23 % par rapport au HTML brut, et le déploiement complet d'un tel pipeline prend 2 à 4 semaines.
Note : Les déclarations et opinions exprimées dans cet article sont celles des auteurs et ne reflètent pas nécessairement les positions d'Adservio.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
Comment nous avons effectué la migration
Les services utilisés pour cette migration sont Azure Blob Storage, Azure Functions, Azure Key Vault, Azure Identity et Azure AI Search. Le choix de l'écosystème Azure était stratégique pour nos clients déjà investis dans Microsoft, mais les principes architecturaux s'appliquent à n'importe quel cloud provider (AWS, GCP).
Les sept phases du pipeline
Configuration de l'environnement : chargement de la configuration, initialisation du client Blob Storage avec authentification par identité managée (zéro credential en clair), authentification OAuth 2.0 vers l'API Confluence et logging structuré JSON vers Azure Application Insights. Récupération et filtrage des espaces : whitelist, blacklist et patterns regex déterminent le périmètre, en excluant les espaces temporaires, archivés ou non pertinents. Extraction du contenu : pages et articles de blog sont récupérés avec pagination, ainsi que leurs métadonnées critiques, body.storage (le HTML natif, plus structuré que body.view), version.number et version.when pour le suivi des changements, ancestors[] pour reconstruire l'arborescence, labels pour la catégorisation sémantique et restrictions pour préserver les ACL.
Transformation du contenu : l'étape la plus critique, conversion du HTML en Markdown propre, nettoyage des chemins et URLs, préparation d'un front matter YAML. La qualité de cette transformation détermine directement le recall, la précision et la pertinence des systèmes RAG construits au-dessus. Opérations de stockage Azure : création du nouveau contenu, mise à jour du contenu modifié et suppression du contenu retiré de Confluence, en maintenant fidèlement la hiérarchie des espaces.
Statistiques et logging : le pipeline suit le nombre de pages ajoutées, mises à jour, supprimées et le temps de traitement par espace. Des alertes automatisées se déclenchent sur seuils : variation de plus de 50 % du delta quotidien de pages, temps de traitement dépassant deux fois la baseline, taux d'erreurs supérieur à 5 % ou croissance de la taille moyenne des documents de plus de 30 % par mois. Finalisation : nettoyage des blobs orphelins, génération de résumés de migration détaillés (JSON et rapport lisible) et notification des erreurs vers les canaux de monitoring (Slack, Teams, PagerDuty).