Enterprise AI Platform - Vue d'ensemble de l'architecture

English - Schéma (HTML + SVG) - Index

1. Couches

Couche	Contenu	Briques
Control Center	Portail Next.js, Control Plane API FastAPI, CLI enterprise-ai, SDK (Python, TypeScript, Java, Go, Realtime), API, GitOps. Administration, portail développeur, sécurité, gouvernance, FinOps, audit	A01, A02, A10 à A14
Identité, accès et application des politiques	Keycloak, SPIFFE/SPIRE, OpenFGA, OPA, points d'application des politiques, OpenBao, cert-manager	A03 à A09
AI Model Gateway	LiteLLM (gateway unifiée), vLLM (moteur d'inférence local), providers distants, registres, routeur, résolveur, effort et contexte, comptage des tokens	B01 à B14
Agent Runtime	Architecture Navin : AgentLoop, AgentRunner, SubagentManager, RunPlan, MessageBus ; worker serveur python -m eai.worker ; sandbox, kill switch, rejeu ; adaptateurs LangGraph et Temporal optionnels	C01 à C15
Capability Gateway	Outils, MCP, skills, plugins	D01 à D08
Integration Gateway	Connecteurs, courtier d'identifiants, webhooks, canaux, événements, API Gateway	D09 à D14
Data and Privacy Gateway	Classification, DLP, tokenisation, chiffrement	E01 à E04
Knowledge Gateway	Traitement de documents, RAG, Qdrant, contexte, mémoire, lignage, rétention	E05 à E13
Multimodal Gateway	Vision, image, vidéo, STT, diarisation, TTS, voix temps réel, VAD	F01 à F12
Qualité et évaluation	Ragas, Promptfoo, garak, orchestrateur qualité	G09, G10, G13, B12
Observabilité, audit et FinOps unifiés	OpenTelemetry, OTel Collector, Opik, ClickHouse, Prometheus, OpenSearch, Alertmanager, audit WORM, quotas, grand livre, tarification	G01 à G08, G11, G12, G14, H01 à H04
Infrastructure souveraine	Kubernetes, Cilium, KEDA, Argo CD, OpenTofu, Kyverno, Trivy, Syft, Cosign, Velero, CI/CD, Harbor, PostgreSQL, Redis, Qdrant, stockage objet, GPU	H05 à H16, E07, E08, E13

Les flèches du schéma sont des interactions logiques, pas un pipeline HTTP unique. vLLM est un moteur d'inférence local ; LiteLLM est la gateway unifiée vers les modèles locaux et distants : vLLM est un upstream de LiteLLM.

2. Principes non négociables

1. Un seul Control Plane : source de vérité unique des registres, politiques, quotas, prix et audit (/v1, voir l'API).
2. Plusieurs runtimes spécialisés : agents (architecture Navin du SDK Python, adaptateurs LangGraph et Temporal optionnels), voix temps réel (LiveKit), batch et médias (workers multimodaux sur NATS), tâches périodiques (python -m eai.worker), inférence (vLLM). Aucun runtime ne détient les données de gouvernance.
3. Gateways obligatoires : modèles, outils, MCP, connaissance, données et multimodal ne sont joignables que par leur gateway. Les agents ne détiennent jamais de clés de provider et n'appellent jamais LiteLLM, vLLM ou un connecteur directement.
4. Télémétrie unifiée : chaque appel porte un traceparent W3C, produit des spans OpenTelemetry, un Usage Event et un événement d'audit chaîné par hash.
5. Les SDK imposent des contrats de développement (manifestes, appels typés, validation locale de contracts/v1), mais ce sont les gateways, les politiques réseau (Cilium) et les identités (SPIFFE, Keycloak) qui appliquent réellement la sécurité. Contourner un SDK ne donne aucun accès supplémentaire.
6. Les exigences de la phase 11 (HA, PRA, charge, sécurité, conformité) s'appliquent dès la phase 1 (feuille de route (catalog/roadmap.yaml)).

3. Modèle multi-tenant

plateforme (opérateur, platform_admin)
  -> tenant (client grand compte) : realm IdP propre ou fédération, quotas, politiques, providers, clés
       -> projets (X-Project)
            -> environnements dev | test | staging | prod (X-Environment)

• Le tenant est résolu depuis l'identifiant, jamais depuis le corps. La RLS PostgreSQL sur tenant_id isole chaque table (eai.tenants, eai.projects, eai.environments, eai.llm_models, eai.llm_providers, eai.policies, eai.audit_events...).
• Les tuples OpenFGA modélisent les relations projets et ressources ; les politiques OPA sont empilées plateforme -> tenant -> projet.
• Les clients des clients consomment soit toute la plateforme (portail + toutes les gateways), soit une seule brique avec son module SDK (par exemple uniquement enterprise_ai.llm.gateway pour le Model Gateway, ou uniquement enterprise_ai.dlp), avec un déploiement minimal : Control Plane + PostgreSQL + le composant de la brique. Exemple de sous-client : client.gateway du SDK Python.

4. Topologies de déploiement

Topologie	Description
Brique seule	Control Plane + PostgreSQL + un composant (ex. gateway LiteLLM), authentification par clés API
SaaS mutualisé	Un cluster, plusieurs tenants isolés par RLS, OpenFGA, namespaces Cilium
Tenant dédié	Namespace ou cluster dédié par grand compte, montage OpenBao et pool GPU propres
Souverain sur site	Cluster isolé du réseau, uniquement des modèles locaux (vLLM), miroir Harbor, Argo CD depuis un Git interne
Hybride	vLLM local pour les données restreintes, providers distants autorisés par politique pour les autres classifications

Toutes sont livrées par Argo CD à partir de charts Helm, d'images signées (Cosign), avec admission Kyverno et sauvegardes Velero.

5. Flux de requêtes

5.1 Appel au Model Gateway

1. Client ou agent : POST /v1/gateway/chat/completions avec l'extension eai.
2. Authentification (JWT, clé API ou SPIFFE) et résolution du tenant.
3. Policy Enforcement (A07 -> OPA/OpenFGA), décision enregistrée.
4. DLP Gateway (E02) sur le prompt : détecter, masquer, tokeniser ou bloquer.
5. Capability Resolver et politique d'effort (B06, B07) : paramètres natifs ou rejet explicite.
6. Context Window Manager (B08) : B_context = W_model - B_output - B_reasoning - B_safety.
7. Estimation et réservation de quota (H03, H01).
8. Le Router (B05) choisit un triplet (provider, modèle, région) autorisé ; LiteLLM (B01) appelle vLLM ou le provider distant ; la bascule (B14) reste dans les listes autorisées.
9. Token Accounting (B09) -> Usage Event -> coût mesuré, validation du quota, événement d'audit, spans vers Opik (voir ARCHITECTURE.md).

5.2 Run d'agent

POST /v1/agents/{id}/runs crée un run pending -> le processus AgentLoop.serve() du client le prend en charge -> AgentRunner exécute le tour : appel modèle via le Model Gateway, puis appels d'outils via la Tool Gateway (politique, DLP, approbation), jusqu'à la réponse finale -> checkpoints et heartbeats à chaque étape -> humain dans la boucle via les approbations -> kill switch disponible à tout moment (le heartbeat répond action=stop) -> Execution Contract (GET /v1/runs/{id}).

Architecture du runtime (Navin, sans graphe déclaré) :

Élément	Rôle
enterprise_ai.loop.AgentLoop	Réception des messages (bus, runs en attente, sessions suivies), contexte, sessions, reprise après crash (resume), arrêt (shutdown), cron et heartbeat, serve()
enterprise_ai.runtime.AgentRunner	Un tour : appel modèle puis appels d'outils jusqu'à la réponse finale, avec les règles de continuation (travail restant, l'utilisateur a déjà donné son feu vert, vérifier avant de finir)
enterprise_ai.subagents.SubagentManager	Sous-agents en parallèle, suivi et injection des résultats dans le tour du parent
enterprise_ai.loop.plan.RunPlan	Plan à étapes dépendantes, avance automatique vers l'étape prête suivante
enterprise_ai.runtime.bus.MessageBus	Bus de messages entre canaux et moteur (en mémoire ou NATS avec NatsMessageBus)
python -m eai.worker	Tâches périodiques du serveur : tick du scheduler, vidage de l'outbox d'événements, expiration des réservations de quota, heartbeats périmés, rétention

LangGraph (enterprise_ai.runtime.langgraph) et Temporal (enterprise_ai.runtime.temporal) sont des adaptateurs optionnels qui réutilisent les mêmes étapes.

5.3 Requête RAG

POST /v1/knowledge-bases/{id}/query -> filtre ACL (OpenFGA) -> recherche Qdrant -> contrôle de classification -> plan du Context Manager -> appel modèle via la gateway -> réponse avec sources ; événement de lignage.

5.4 Session vocale temps réel

POST /v1/realtime/sessions renvoie un jeton LiveKit, une URL ws et un id de session. L'audio circule en WebRTC (pas en HTTP), la VAD (Silero) le segmente, STT (faster-whisper) -> agent ou modèle -> TTS (Piper) ; événements sur /v1/realtime/ws/{session_id} (transcript.delta, response.audio.delta, usage.update). L'usage est mesuré à la seconde et au token.

5.5 Cycle FinOps

Étape	Source	API
Estimé	grille tarifaire x unités prévues, avant l'appel	POST /v1/gateway/estimate, POST /v1/finops/estimate
Mesuré	Usage Event après l'appel (tokens, secondes, temps GPU)	POST /v1/finops/usage
Facturé	import de facture ou d'export du provider, rapprochement	POST /v1/finops/reconciliation/run, GET /v1/finops/reconciliation/report

6. Vue d'ensemble des contrats

Les JSON Schemas partagés de contracts/v1/ sont la source de vérité du Control Plane, des gateways, du portail, des SDK et de la CLI : common, agent-manifest, model-manifest, tool-manifest, skill-manifest, plugin-manifest, connector-manifest, channel-manifest, policy-contract, execution-contract, context-contract, memory-contract, multimodal-contract, evaluation-contract, usage-event, audit-event. Ils sont validés par POST /v1/contracts/{name}/validate, appliqués par POST /v1/manifests/apply et vérifiés côté client par chaque SDK.

Catalogue des briques : catalog/bricks.yaml (servi par GET /v1/catalog/bricks).