Déployer des agents IA sur Kubernetes : architecture, mise à l'échelle et quand K8s devient rentable

Déployer des agents IA sur Kubernetes consiste à exploiter les composants d'un système d'agents (service d'agent, serveurs d'outils ou MCP, base vectorielle, moteur d'inférence et file de messages) sous forme de charges de travail conteneurisées sur un cluster K8s. Kubernetes apporte la mise à l'échelle, l'ordonnancement des GPU, la gestion de l'état, la gestion des secrets et l'observabilité pour exploiter des agents en production en toute souveraineté européenne. C'est puissant, mais ce n'est pas une fin en soi. Cet article présente l'architecture, la mécanique de mise à l'échelle et surtout le moment où l'effort devient réellement rentable.

• Architecture : découpe le système d'agents en services découplés (orchestrateur, serveurs d'outils/MCP, moteur d'inférence, base vectorielle, file de messages) et exploite chacun comme une charge de travail distincte.
• Mise à l'échelle : les pods d'agent sans état sont mis à l'échelle de manière élastique via le Horizontal Pod Autoscaler ; les pods d'inférence GPU sont placés sur des nœuds GPU dédiés et restent à chaud pour des raisons de coût.
• Décision : Kubernetes devient rentable avec une charge continue élevée ou des exigences strictes de souveraineté ou de latence. En dessous, les API managées et le serverless sont plus rapides à mettre en production et moins chers.

L'architecture de conteneurs d'un système d'agents

Un agent IA en production n'est pas un monolithe, mais un ensemble de microservices. Ce découpage n'est pas une fin en soi : il répond aux profils de mise à l'échelle, d'état et de sécurité propres à chaque composant.

Service d'agent (orchestrateur)

Le service d'agent est le cerveau : il exécute la logique d'orchestration, décide des appels d'outils et planifie les étapes. Il repose généralement sur un framework comme LangGraph, CrewAI ou AutoGen, ou sur une plateforme éditeur comme PhariaAI (Heidelberg) ou Microsoft Foundry Agent Service (anciennement Azure AI Foundry Agent Service). Point décisif sur le plan architectural : ce service doit rester stateless pour que Kubernetes puisse librement le mettre à l'échelle, le redémarrer et le répartir sur plusieurs réplicas. Tout l'état est déporté vers des stockages externes.

Serveurs d'outils et MCP

Le Model Context Protocol (MCP) s'est imposé comme l'interface standard par laquelle les agents accèdent aux outils et sources de données externes. Dans un environnement d'entreprise de la région DACH (Allemagne, Autriche, Suisse), les serveurs MCP tournent le plus souvent comme services internes au VPC, colocalisés avec le runtime de l'agent et connectés via mTLS. C'est le modèle par défaut pour les intégrations avec SAP, Salesforce, ServiceNow, M365 et les bases de données internes. Pour les scénarios d'usine ou de succursales, les serveurs MCP sont déployés en edge, au plus près des données, et l'orchestration centrale les appelle via des liaisons dédiées (ExpressRoute, Direct Connect). Pour les charges réglementées, la règle est la suivante : des serveurs MCP dédiés par business unit avec des pistes d'audit séparées plutôt qu'un serveur multi-tenant.

Moteur d'inférence

C'est ici que tourne le modèle de langage. En 2026, le choix est bien circonscrit :

• vLLM (issu de l'UC Berkeley) est le standard de fait pour l'auto-hébergement en production : PagedAttention, la plus large compatibilité matérielle, endpoints compatibles OpenAI.
• SGLang (LMSYS) offre, d'après les benchmarks LMSYS, environ 29 % de débit en plus sur les modèles 7B–8B sur H100 et une meilleure latence de queue ; idéal pour le chat multi-tours, les charges riches en RAG et les charges structurées.
• NVIDIA NIM regroupe vLLM/TensorRT-LLM/SGLang dans des conteneurs préconfigurés et constitue la voie on-premise la plus pragmatique pour les PME de la région DACH, mais il est lié à la licence NVIDIA AI Enterprise.
• TensorRT-LLM offre un débit de pointe sur le matériel NVIDIA, mais il est réservé à NVIDIA et exigeant à exploiter.

Remarque importante pour les systèmes existants : Hugging Face a placé TGI (Text Generation Inference) en mode maintenance le 11 décembre 2025 et redirige les nouveaux déploiements vers vLLM ou SGLang. Si tu utilises TGI aujourd'hui, pas besoin de migrer dans la panique, mais évite d'y bâtir de nouveaux développements.

Base vectorielle et file de messages

La base vectorielle (Qdrant, Weaviate ou pgvector) stocke les embeddings pour le RAG. C'est un candidat classique au StatefulSet avec PersistentVolumes, car les embeddings et les chunks d'origine atteignent des tailles de l'ordre du téraoctet et ont besoin d'une identité de pod stable et d'un stockage persistant. Une file de messages (par exemple RabbitMQ, NATS ou Redis Streams) découple les tâches d'agent longues et asynchrones (traitement de documents, analyses par lots) du chemin de requête synchrone et permet des pools de workers qui évoluent indépendamment.

Correspondance des composants : quelle ressource K8s pour quoi

Le tableau suivant est la référence centrale pour un déploiement d'agents. Il associe chaque composant à la ressource Kubernetes adaptée et indique la remarque d'architecture déterminante.

Mise à l'échelle : HPA, ordonnancement des GPU et les deux axes

Les stacks d'agents se mettent à l'échelle sur deux axes totalement différents, et c'est l'écueil le plus fréquent.

Axe sans état (CPU) : le service d'agent, les serveurs MCP et l'AI Gateway sont des charges CPU peu coûteuses. Ils sont mis à l'échelle de manière élastique via le Horizontal Pod Autoscaler (HPA) : lors des pics de charge, des réplicas s'ajoutent, et en période creuse, ils sont supprimés. Pour les workers pilotés par file, KEDA convient bien, car il se base sur la profondeur de la file et pas seulement sur le CPU.

Axe GPU (inférence) : ici, une autre logique s'applique. Les nœuds GPU sont déclarés au cluster via le NVIDIA Device Plugin ; les pods demandent des GPU via la limite de ressources nvidia.com/gpu. Grâce aux node selectors, taints et tolerations, les pods d'inférence atterrissent précisément sur les nœuds GPU coûteux, tandis que les charges sans état restent sur des nœuds CPU. La différence centrale : la capacité GPU reste le plus souvent à chaud plutôt qu'élastique, car des GPU inactifs constituent le capex le plus coûteux qui soit. Une véritable élasticité via le Cluster Autoscaler ne fonctionne que là où le fournisseur cloud livre des nœuds GPU suffisamment vite. Avec une capacité Blackwell dédiée et soumise à allocation (B200/GB200), ce n'est pas le cas.

Le calcul de la mémoire GPU détermine combien de modèles tiennent sur un nœud. Règle empirique pour les poids : nombre de paramètres multiplié par les octets par paramètre. Un modèle 70B nécessite environ 140 Go en BF16 (2 octets), environ 70 Go en FP8, environ 35 Go en AWQ-INT4, auxquels s'ajoute le cache KV, qui croît avec la taille du batch et la longueur de séquence (de l'ordre de 10–40 Go en production). En pratique, un modèle 70B ne tient sur un seul H200 (141 Go) qu'une fois quantifié, par exemple en FP8 avec environ 70 Go plus le cache KV. En BF16, les poids ne laissent quasiment pas de place au cache KV. Il faut alors du parallélisme tensoriel sur plusieurs GPU d'un même nœud via NVLink. Sur le papier, deux H100 (160 Go au total) ne suffisent pas pour les poids et le cache KV. Pour des tailles de batch de production, il faut donc deux H200 (282 Go) ou quatre H100 (320 Go).

État, mémoire et région UE

Contrairement aux applications web classiques, les agents sont stateful : la mémoire conversationnelle, les plans de tâches et l'historique des appels d'outils doivent survivre, même si un pod redémarre ou si un basculement de région se produit. Sur le plan architectural, cela signifie : état de session dans un Redis régional ou dans Cosmos DB avec géoréplication, mémoire à long terme et base vectorielle répliquées de façon synchrone ou asynchrone, selon le RPO exigé. La base vectorielle représente ici le défi des données volumineuses, car les embeddings et les chunks constituent les plus grands volumes de données.

C'est sur la question de la région UE et de la souveraineté que se cache le piège principal : la région de Francfort d'un hyperscaler américain offre la résidence des données, pas une souveraineté résistante au CLOUD Act, car l'exploitant reste une personne morale américaine. Pour du Kubernetes managé véritablement souverain, les clouds souverains entrent en jeu : Infomaniak (Genève/Zurich, contrôle entièrement suisse, LPD et RGPD) et Exoscale (Suisse, base CloudStack avec ses propres orchestrateurs, K8s managé) proposent du Kubernetes managé sans exposition aux hyperscalers ; Swisscom dispose d'un service K8s souverain basé sur Kubermatic ; STACKIT (Schwarz Digits, avec un centre de données en Autriche) et Open Telekom Cloud misent sur des plateformes basées sur OpenStack avec des instances GPU. Pour les charges sans exigence stricte de souveraineté, le Kubernetes managé des hyperscalers (AKS/EKS/GKE) dans une région UE reste le choix pragmatique par défaut ; c'est d'ailleurs ainsi que le résout l'architecture de référence pour les scale-ups lean.

Secrets, accès aux outils et observabilité

Les agents ont un rayon d'impact inhabituellement large : un agent compromis peut appeler de nombreux outils. La bonne pratique consiste donc à utiliser un compte de service par couple agent-outil plutôt qu'un compte partagé, une élévation de privilèges just-in-time pour les opérations sensibles et des pistes d'audit qui remontent jusqu'à l'identité de l'utilisateur via une chaîne d'échange de tokens.

Concrètement, sur Kubernetes :

• Workload Identity plutôt que des identifiants statiques : Azure Managed Identity, AWS IRSA (IAM Roles for Service Accounts dans EKS), GCP Workload Identity Federation et, sur les clouds souverains, les comptes de service Keystone ou K8s. L'objectif est identique : aucune clé dans le code, aucun humain dans le chemin des identifiants.
• Socle de secrets : HashiCorp Vault est la couche de secrets et de PKI la plus répandue dans les stacks de plateforme de la région DACH ; dans le BFSI et le secteur public, avec un scellement sur un HSM Utimaco (Aix-la-Chapelle) ou Thales. Le pattern External Secrets les synchronise dans des secrets K8s sans les stocker dans le dépôt.
• Contrôle de l'egress : le modèle établi dans le BFSI de la région DACH est le deny-by-default avec une allowlist explicite des FQDN des API de modèles, journalisée au niveau du gateway. Cela évite toute exfiltration accidentelle de données et force tout le trafic vers les modèles à passer par l'AI Gateway (LiteLLM, Portkey, Kong), où se trouvent les rate limits, les filtres PII et les budgets.

Pour la santé et l'observabilité, Kubernetes fournit la base : les probes de liveness et de readiness par pod garantissent que seuls les pods d'inférence en bonne santé reçoivent du trafic, ce qui est critique avec des temps de chargement de modèle longs (la readiness probe ne doit passer au vert qu'une fois le modèle chargé). Par-dessus vient une couche de tracing via OpenTelemetry, avec une attribution des coûts au token près et un backend hébergé dans l'UE comme Langfuse (auto-hébergé).

Quand choisir Kubernetes, et quand s'en passer

Voici l'avertissement honnête sur la complexité. Kubernetes avec une inférence GPU auto-hébergée n'est pas un projet de week-end. Il devient rentable si au moins un de ces facteurs s'applique :

• Charge élevée et régulière : selon une règle empirique qui circule dans les équipes plateforme de la région DACH, l'inférence auto-hébergée devient moins chère par token que les API managées à partir d'environ 8–12 H100 équivalents en charge continue, mais avec 6–9 mois de préparation côté ingénierie. En dessous, les API managées l'emportent sur le TCO.
• Latence stricte : des budgets de latence inférieurs à 200–500 ms avec plusieurs allers-retours d'appels d'outils exigent une inférence colocalisée ; les appels d'API transatlantiques (Francfort → US-East : environ 85–95 ms aller-retour) sont alors disqualifiés.
• Souveraineté contractuelle : lorsque le service juridique n'accepte pas l'exposition au CLOUD Act ou que BSI C5 Type 2 est contraignant.

À l'inverse, les API managées et le serverless s'imposent lorsque la charge fonctionne par pics (des GPU inactifs sont le pire des capex), lorsqu'une grande diversité de modèles est nécessaire (rien qu'en 2025, Microsoft Foundry a ajouté DeepSeek R1, GPT-4.1, Mistral Large 3, Claude Opus 4.5 et Llama 4) ou tout simplement lorsqu'il n'y a pas d'équipe plateforme. Rares sont les PME de la région DACH qui maîtrisent en interne l'exploitation de vLLM, l'ordonnancement des GPU et les erreurs typiques de NCCL en mode 24x7, et c'est précisément ce manque, et non la technique elle-même, qui explique le plus souvent l'échec des projets d'auto-hébergement.

Exemple concret : un cluster lean pour un agent B2B

Une stack typique de scale-up (inspirée de l'architecture de référence « Lean Cloud ») ressemble à ceci :

```text
Kubernetes managé (AKS/EKS en région UE ou Exoscale/Infomaniak souverain)
├── Deployment: agent-orchestrator (LangGraph, 3 réplicas, HPA 2-10, nœuds CPU)
├── Deployment: mcp-tools-sap (mTLS, 1 compte de service par outil)
├── Deployment: ai-gateway-litellm (Failover: Azure OpenAI EU -> Mistral La Plateforme)
├── StatefulSet: qdrant (3 réplicas, PVC, base vectorielle)
├── StatefulSet: redis (état de session, géoréplication)
└── Worker-Deployment: doc-processor (KEDA, mise à l'échelle selon la profondeur de file RabbitMQ)
Inférence du modèle : API managée (pas de nœud GPU dédié) -> via le gateway
```

Ici, aucun GPU en propre ne tourne. L'inférence est assurée par une API managée hébergée dans l'UE, abstraite derrière le gateway. C'est voulu : avec une charge modeste, le paiement au token est moins cher et opérationnel en quelques semaines plutôt qu'en plusieurs mois. Ce n'est que lorsque les dépenses API mensuelles dépassent le run rate d'environ 10 H100 équivalents dans un cloud souverain, ou qu'une nouvelle exigence réglementaire impose un contrôle que l'API managée ne peut pas démontrer, que la migration vers des nœuds GPU en propre avec vLLM ou NIM sur le même cluster devient rentable. C'est précisément là que Kubernetes excelle : l'architecture reste la même, seul le composant d'inférence passe de « API managée derrière le gateway » à « déploiement GPU dans le cluster ».

Pour les agences et les décideurs B2B

Kubernetes est la bonne base pour les systèmes d'agents appelés à croître sur le long terme, à rester souverains au sens européen ou à respecter une latence stricte, mais l'entrée devrait presque toujours se faire via des API managées et du Kubernetes managé, avec un déclencheur de migration clairement documenté pour le passage à une inférence GPU en propre. Si tu ne définis pas ce seuil proprement, tu construiras un cluster GPU coûteux soit trop tôt, soit trop tard, quand la facture API aura déjà dérapé. Blck Alpaca accompagne les entreprises en Europe et les agences marketing précisément dans cette décision d'architecture : de l'évaluation make-buy-rent par composant jusqu'à la conception d'un cluster souverain et prêt pour l'observabilité. Contacte-nous avant de commander le premier GPU.