← Ingénierie IA et IA agentique
Infrastructure de déploiement · production AKS · IaC Bicep

ERP agentique : l'infrastructure de déploiement

La chaîne qui met le copilote sur une infrastructure réelle, avec les 6 contrôles à passer avant qu'une version atteigne un utilisateur.

6
Modules d'infrastructure Bicep
AKS, ACR, Postgres, Redis, CosmosDB, Monitor
2
Surcouches Kustomize
préproduction et production
6
Contrôles du test de fumée
santé, documentation, WebSocket, porte humaine, injection, interface
OIDC
Méthode d'authentification
sans clé, aucun identifiant de registre dans l'intégration continue

Une architecture d'intégration continue à deux dépôts

Le dépôt de développement fait tourner une chaîne GitHub Actions à 6 tâches à chaque envoi sur master : portes de qualité côté serveur (ruff, black, mypy, bandit, tests unitaires pytest), tsc côté interface, tests d'intégration, une tâche d'équipe rouge (promptfoo), et une construction qui envoie les images vers Azure Container Registry avec une authentification OIDC sans clé. Un événement repository_dispatch déclenche ensuite ce dépôt de déploiement.

Ce dépôt de déploiement reçoit l'événement et lance une tâche de déploiement qui attend une approbation manuelle par un environnement GitHub. Une fois approuvée, la tâche exécute kubectl apply, puis rollout wait, puis le test de fumée à 6 contrôles. Garder le déploiement dans son propre dépôt trace la frontière de production là où un relecteur la voit : aucun commit n'atteint la production sans une seconde paire d'yeux.

L'infrastructure en code : les modules Bicep

Module Détail
AKS Un groupe de nœuds système (Standard_D2s_v3) et un groupe de nœuds GPU (Standard_NC6s_v3), avec l'émetteur OIDC activé pour une identité de charge de travail sans clé.
Azure Container Registry Référence Premium avec géoréplication. GitHub Actions envoie par OIDC, donc aucun identifiant de registre ne dort dans les secrets d'intégration continue.
Postgres (Flexible Server) pgvector activé, accessible uniquement par un point de terminaison privé, avec SSL imposé.
Redis Cache Référence Standard C1, qui porte le cache sémantique (recherches SHA-256 et cosinus) et les UUID de décision de la porte humaine (durée de vie de 24 heures).
CosmosDB Sans serveur, avec des réplicas de lecture multi-régions. Il garde l'historique des conversations et les journaux d'audit.
Azure Monitor / App Insights Le DaemonSet OTel transmet les traces et les métriques OTLP. Les tableaux de bord couvrent la latence des solveurs, le taux de succès du cache et le volume de décisions de la porte humaine.

Les surcouches Kustomize

Un jeu de manifestes Kubernetes de base (Deployment, Service, ConfigMap, HorizontalPodAutoscaler) est partagé entre les environnements. Les surcouches Kustomize corrigent uniquement ce qui diffère entre la préproduction et la production : nombre de réplicas, demandes et limites de ressources, et étiquettes d'image. Aucun manifeste n'est dupliqué.

Le contrôleur d'entrée NGINX oriente /api et /ws vers le serveur FastAPI, et / vers l'interface Vite. Les en-têtes de montée en version WebSocket sont transmis explicitement, pour que le canal de notification de la porte humaine passe l'entrée au lieu de s'y perdre en silence.

L'observabilité : le DaemonSet OTel

Un DaemonSet OpenTelemetry Collector tourne sur chaque nœud AKS et reçoit les traces et les métriques OTLP des pods applicatifs, puis les transmet à Azure Monitor Application Insights par l'exportateur OTLP/HTTP. Les tableaux de bord suivent la latence des solveurs par intention (mcnf_solve, vrp_route et les autres), le taux de succès du cache Redis, le volume de décisions de la porte humaine avec son taux d'approbation, et les résultats des sondes d'équipe rouge de la porte d'intégration continue.

Le test de fumée : 6 contrôles

Une fois que kubectl rollout status annonce un état sain, le script smoke-test.sh enchaîne 6 contrôles et s'arrête à la première erreur :

  • Point de terminaison de santé. GET /health renvoie 200.
  • Documentation OpenAPI. GET /docs renvoie 200, ce qui confirme que FastAPI a démarré correctement.
  • Accessibilité WebSocket. Une brève poignée de main vers le canal de notification de la porte humaine aboutit.
  • Routeur de la porte humaine. Un appel de solveur de test au-delà du seuil de 10 000 $ atteint le nœud de porte et renvoie un état « en attente » plutôt qu'une erreur.
  • Sonde d'injection. Une chaîne d'injection d'instruction connue revient rejetée, ce qui confirme que le nettoyeur de données personnelles et la couche RBAC sont actifs.
  • Accessibilité de l'interface. GET / renvoie 200 avec le HTML du paquet Vite.

La posture de sécurité

Postgres, Redis et CosmosDB se tiennent derrière des points de terminaison privés et restent inaccessibles depuis l'internet public. L'identité de charge de travail AKS (OIDC) authentifie les pods auprès des ressources Azure sans identifiants statiques, et le flux GitHub Actions passe par une fédération OIDC pour envoyer les images vers ACR, donc aucun mot de passe de registre n'est stocké nulle part. Les jetons JWT d'accès à l'API utilisent HS256 avec une expiration à 60 minutes.

  • Azure AKS
  • Bicep
  • Kustomize
  • GitHub Actions
  • OIDC
  • OTel
  • Azure Monitor
  • NGINX ingress
  • Postgres + pgvector
  • Redis
  • CosmosDB
  • ACR