Déployer un agent IA Azure sans sortir du réseau privé

Un agent IA Azure devient réellement intéressant quand il dépasse le simple chatbot. Le cas d’usage utile n’est pas de demander au modèle de répondre de manière générale, mais de lui donner un périmètre clair : lire des données internes, raisonner sur une demande, appeler un outil autorisé, produire une trace exploitable et rester dans une architecture réseau maîtrisée. Dans une entreprise qui limite son exposition Internet, cette différence est essentielle.

Le scénario retenu ici est concret. Une équipe infrastructure veut un agent capable d’aider à diagnostiquer des incidents simples sur des services internes. L’agent doit interroger une base documentaire indexée dans Azure AI Search, consulter quelques métadonnées techniques, puis déclencher une action encadrée via une Logic App ou une API interne. Il ne doit pas avoir un accès large au réseau, ne doit pas appeler librement Internet et ne doit pas posséder de droits génériques sur l’abonnement Azure.

L’objectif n’est donc pas de créer un agent autonome qui peut tout faire. L’objectif est de construire un agent borné, connecté à des outils précis, avec des identités séparées, des logs et un chemin réseau explicable.

Définir le cas d’usage avant les outils

Le premier piège consiste à commencer par les outils. Un agent peut appeler Azure AI Search, un stockage, une Logic App, une API, un connecteur ou un moteur de recherche. Mais si le cas d’usage n’est pas borné, chaque outil ajouté augmente le risque. Pour un premier agent de production, il vaut mieux choisir une action simple et une base de connaissance limitée.

Dans ce scénario, l’agent reçoit une demande comme : pourquoi une application interne ne répond plus depuis un spoke Azure ? Il ne doit pas modifier le firewall ni redémarrer des services. Il doit d’abord produire un diagnostic guidé à partir de procédures internes, puis proposer une action de collecte ou de vérification.

Cas d'usage initial
Aider au diagnostic d'incidents infrastructure simples
Répondre à partir d'une base documentaire interne
Déclencher uniquement des actions de collecte ou de vérification
Produire une trace lisible pour l'exploitation

Hors périmètre au démarrage
Modification de règles firewall
Suppression ou redémarrage de ressources
Changement de configuration réseau
Exécution de commandes libres
Accès Internet non contrôlé

Ce cadrage change la conception. L’agent n’est pas un administrateur. Il est un assistant d’exploitation qui lit, raisonne, demande une confirmation si nécessaire et appelle des outils limités.

Séparer connaissance et action

Un agent utile combine souvent deux familles d’outils. Les outils de connaissance donnent du contexte. Les outils d’action déclenchent quelque chose. Il faut les séparer dès le départ, car ils ne portent pas le même risque.

La connaissance peut venir d’Azure AI Search, alimenté par des procédures internes, des runbooks, des schémas d’architecture, des règles d’exploitation ou des articles techniques. L’action peut passer par une Logic App, une Function ou une API interne qui expose uniquement quelques opérations autorisées.

Agent Azure AI Foundry
Modèle de raisonnement
Instructions système strictes
Outil de connaissance: Azure AI Search
Outil d'action: Logic App ou API interne

Azure AI Search
Index de runbooks et procédures
Pas de secrets dans les documents
Métadonnées de source et date

Logic App ou API interne
Actions limitées
Entrées validées
Logs détaillés
Retour structuré vers l'agent

Cette séparation facilite le diagnostic. Si une réponse est mauvaise, on regarde l’index et le grounding. Si une action est dangereuse, on regarde l’outil d’action et ses permissions. Mélanger les deux dans une logique trop libre rend l’agent difficile à auditer.

Construire l’index documentaire

Le premier composant exploitable est l’index Azure AI Search. Il ne suffit pas d’envoyer un vrac de documents. Les contenus doivent être découpés, nommés et enrichis avec des métadonnées utiles. Un runbook réseau, une procédure DNS et un guide Active Directory doivent être distingués. La date, le périmètre et le niveau de confiance doivent être visibles.

{
"id": "runbook-private-dns-001",
"title": "Diagnostic Private DNS Zone Azure",
"category": "networking",
"environment": "production",
"lastReviewed": "2026-04-20",
"source": "internal-runbook",
"content": "Procedure de diagnostic DNS prive Azure..."
}

L’agent doit être invité à citer la source interne qu’il utilise dans sa réponse opérationnelle, au moins dans les logs ou dans la trace de conversation. Cela ne signifie pas afficher des citations publiques dans l’article ou dans l’interface finale. Cela signifie qu’un exploitant doit pouvoir comprendre pourquoi l’agent propose telle étape.

Une base documentaire non gouvernée produit un agent confus. Si les runbooks sont obsolètes, contradictoires ou sans date, l’agent amplifie ce désordre. Le travail d’architecture agentique commence donc par une hygiène documentaire minimale.

Encadrer les actions avec une API étroite

L’erreur classique consiste à donner à l’agent un accès trop large à une API d’administration. Pour un premier usage, l’outil d’action doit être étroit. Une Logic App ou une Function peut exposer une opération comme checkDnsResolution, collectVmNetworkState ou getServiceHealth. L’agent ne choisit pas une commande libre. Il appelle une action prédéfinie.

{
"action": "checkDnsResolution",
"input": {
  "hostname": "app01.internal.example",
  "sourceNetwork": "spoke-prod-01"
},
"allowedEnvironments": ["preproduction", "production"],
"requiresApproval": false
}

Le contrat d’entrée doit être validé côté outil. L’agent peut se tromper, mal comprendre une demande ou recevoir une instruction ambiguë. La Logic App ou l’API ne doit pas exécuter aveuglément tout ce que le modèle demande. Elle doit vérifier le format, le périmètre, l’environnement et l’autorisation.

Pour les actions sensibles, il faut une validation humaine. L’agent peut préparer l’action, expliquer l’impact et demander confirmation. L’outil doit refuser l’exécution si l’approbation n’est pas présente.

Utiliser l’identité managée comme limite

L’identité est un garde-fou central. L’agent et ses outils ne devraient pas utiliser de secrets statiques déposés dans du code. Les identités managées permettent de donner des droits précis aux composants Azure, puis de les auditer dans Entra ID et Azure RBAC.

Le modèle minimal consiste à séparer l’identité qui interroge la connaissance de celle qui déclenche l’action. L’accès à Azure AI Search n’a pas le même risque que l’accès à une Logic App qui collecte des informations sur une VM. Si une identité est compromise ou mal configurée, son périmètre doit rester limité.

Identite agent-knowledge-reader
Lecture de l'index Azure AI Search
Pas de droit d'action sur les ressources Azure

Identite agent-action-runner
Appel d'une Logic App ou Function precise
Pas de droit general Contributor
Permissions limitees au groupe de ressources utile

Identite humaine
Validation des actions sensibles
Acces aux logs et traces d'audit

Le rôle Contributor générique est à éviter. Un agent qui reçoit un droit trop large devient une surface d’automatisation difficile à contrôler. Les permissions doivent suivre les actions réellement exposées, pas les ambitions futures.

Garder le réseau privé explicable

Pour un environnement Naxaya typique, l’agent ne doit pas être imaginé hors du réseau. Le design doit préciser où sont les endpoints privés, quelles zones DNS privées sont utilisées, quels subnets sont nécessaires, et comment l’agent atteint Azure AI Search, Storage, Cosmos DB ou l’API interne.

Azure AI Foundry Agent Service peut être déployé avec une approche réseau privée. Le point important côté architecture est de rendre le chemin lisible : agent, subnet dédié, private endpoints, Private DNS Zones, puis ressources privées. Si l’équipe ne sait pas expliquer ce chemin, le diagnostic sera difficile dès le premier incident.

Agent subnet
Execute l'agent dans un environnement isole

Private endpoint subnet
Foundry
Azure AI Search
Storage
Cosmos DB si utilise
API interne si exposee via Private Link

Private DNS Zones
privatelink.openai.azure.com
privatelink.search.windows.net
privatelink.blob.core.windows.net
privatelink.services.ai.azure.com

Le DNS privé devient une dépendance directe de l’agent. Si l’agent ne résout pas l’index, le stockage ou l’API interne, il ne peut pas fonctionner. Les tests de résolution doivent donc faire partie du déploiement, comme pour n’importe quelle application privée.

Journaliser les décisions et les actions

Un agent d’exploitation doit être observable. Il ne suffit pas de savoir qu’une réponse a été produite. Il faut savoir quel utilisateur a fait la demande, quels documents ont été consultés, quel outil a été appelé, quels paramètres ont été envoyés, quelle réponse l’outil a retournée et si une validation humaine a été demandée.

{
"requestId": "agt-20260427-001",
"user": "operator@example.com",
"agent": "infra-diagnostic-agent",
"knowledgeSources": ["runbook-private-dns-001"],
"toolCalled": "checkDnsResolution",
"approved": false,
"result": "private_dns_resolution_failed"
}

Ces logs doivent être exploitables par l’équipe. Un agent qui agit sans trace devient rapidement suspect. Un agent qui laisse une piste claire peut être intégré progressivement dans les pratiques d’exploitation.

Tester l’agent comme une application critique

La validation ne doit pas porter uniquement sur la qualité des réponses. Il faut tester les chemins d’échec. Que se passe-t-il si Azure AI Search ne répond pas ? Si l’API interne retourne une erreur ? Si l’utilisateur demande une action hors périmètre ? Si le document interne est obsolète ? Si le réseau privé ne résout plus la zone attendue ?

Tests avant production
Question couverte par un runbook valide
Question absente de la base documentaire
Demande d'action hors périmètre
API interne indisponible
DNS prive casse vers Azure AI Search
Identite sans permission suffisante
Action sensible sans approbation

Un bon agent refuse proprement. Il doit dire quand il ne sait pas, quand il manque une source, quand l’action n’est pas autorisée et quand une validation humaine est nécessaire. Ce comportement est plus important qu’une réponse longue.

Conclusion

Un agent IA Azure exploitable n’est pas un modèle auquel on donne beaucoup d’outils. C’est une application d’automatisation avec un périmètre, des sources, des identités, un réseau, des logs et des refus explicites. Azure AI Foundry Agent Service apporte la couche agentique, les outils et l’hébergement managé, mais la qualité du résultat dépend surtout du design opérationnel autour de l’agent.

Le bon premier cas d’usage n’est pas un agent capable de tout administrer. C’est un agent capable de répondre à un incident simple, de s’appuyer sur un index documentaire propre, d’appeler une action bornée, de rester dans le réseau privé et de laisser une trace. Cette base suffit déjà à produire de la valeur sans créer une nouvelle surface incontrôlée dans l’infrastructure.