BI Multi-Agent Hub

Architecture multi-agent

L'orchestrateur découpe la question métier, délègue aux spécialistes, vérifie les preuves, puis produit un rapport sourcé.

Lancer une analyse →
Flux d'orchestration · scénario marge juin vs mai
🙂 Question
🧭 Orchestrateur
🗄️ SQL
📊 Analyste
📚 RAG
🌐 Web
✅ Qualité
📝 Rapport
Appelé En cours En attente

Les agents

🧭 Orchestrateur

Planifie, délègue, contrôle l'ordre, gère les erreurs.

In Question, état global
Out Plan, routage

🗄️ SQL Agent

Requêtes SQL lecture seule via outil validé (jamais d'accès direct LLM → base).

In Schéma, tâche analytique
Out SQL, métriques

📊 Data Analyst

Interprète les agrégats : segments, tendances, anomalies.

In Résultats SQL
Out Causes segmentées

📚 RAG Agent

Politiques et procédures internes (LanceDB + citations).

In Question, index
Out Extraits sourcés

🌐 Web Research

Contexte externe seulement si la donnée interne manque.

In Requête reformulée
Out Sources datées

✅ Quality Agent

Chaque chiffre ↔ SQL ; chaque règle ↔ document ; hypothèses signalées.

In Sorties agents
Out Validé / à corriger

📝 Report Agent

Rapport structuré : résumé, causes, actions, sources, limites.

In Faits validés
Out Réponse finale

Stack technique

Frontend · Jinja + SSE
→
FastAPI · Auth · Audit · Cache
→
LangGraph · Supervisor
→
DuckDB + LanceDB
→
Groq · gpt-oss-120b

Le LLM n'accède jamais directement à la base : l'agent SQL passe par un outil qui valide le SELECT, limite le volume et journalise l'exécution.