![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(92.8, 14.000000000000002%, 18%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Microsoft Foundry
Une plateforme Azure unifiée permettant de créer et de gérer des modèles, des agents et des applications IA avec la sécurité, la supervision et la gouvernance d’entreprise intégrées
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(6.4, 51%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKV%3C/text%3E%3C/svg%3E)
Bonjour ATG,
La réponse suivante a été rédigée à l'origine en anglais, puis traduite.
Bienvenue sur Microsoft Q&A. Merci de nous avoir contactés.
L’ensemble des éléments disponibles confirme que la configuration de l’environnement est correcte et complète.Le comportement HTTP 503 de l’API Agents reflète une limitation côté service affectant le chemin du plan de contrôle Projects en France Centre, tandis que les services d’exécution IA principaux restent opérationnels.La résolution dépend de la stabilisation du backend, et aucune action supplémentaire n’est requise du côté de l’environnement.
Explication du comportement observé
Azure AI Foundry fonctionne en mode réseau privé avec Bring Your Own Resources (BYOR) dans la région France Centre. Les dépendances principales telles que Cosmos DB, Storage et Azure AI Search sont correctement provisionnées, associées à l’hôte de capacité et accessibles via des points de terminaison privés.
Dans cet environnement, deux chemins d’API distincts présentent des comportements différents :
- Les API Assistants retournent systématiquement HTTP 200, confirmant que l’authentification, le réseau privé, la résolution DNS et la couche d’exécution IA fonctionnent correctement.
- Les API Agents, accessibles via le point de terminaison Projects, retournent systématiquement HTTP 503 avec un corps de réponse vide, avec un délai d’environ 10 à 15 secondes avant l’échec.
Ce schéma confirme que les requêtes atteignent correctement le point d’entrée du service, mais échouent lors du traitement côté backend dans la couche d’orchestration des Agents, avant qu’une réponse d’erreur structurée ne puisse être générée.
Pourquoi les Assistants fonctionnent tandis que les Agents échouent
Ce comportement s’explique par une séparation des responsabilités côté backend :
- Les API Assistants fonctionnent via la couche d’exécution du plan de données, axée sur l’exécution des modèles et comportant moins de dépendances de service.
- Les API Agents s’appuient sur le plan de contrôle Foundry Projects, qui comprend les services d’orchestration responsables de la gestion du cycle de vie des agents, du traitement des métadonnées et de la coordination des dépendances entre Cosmos DB, Storage et AI Search.
Lorsque la couche d’orchestration rencontre une instabilité ou des contraintes de capacité, les API Agents peuvent retourner HTTP 503 alors que les Assistants restent pleinement opérationnels. Cette distinction correspond aux entrées AzureDiagnostics observées, où Projects_Wildcard_Get échoue tandis que d’autres appels au niveau du projet réussissent.
Lorsque des réponses HTTP 503 persistent dans cet état, la cause est généralement liée à l’initialisation backend côté service, à des délais de propagation ou à la disponibilité des dépendances, plutôt qu’à une configuration environnementale incomplète.
Des comportements similaires spécifiques aux Agents ont été observés en France Centre, en particulier dans des scénarios de réseau privé.Ces occurrences sont généralement associées à des conditions de disponibilité ou de capacité backend au sein de la couche d’orchestration des Agents Foundry.
Ces conditions ne figurent pas toujours sur les pages publiques d’état du service, car elles peuvent être spécifiques à un stamp ou à un service, mais elles sont surveillées et atténuées par les équipes d’ingénierie de la plateforme.
Les étapes suivantes sont recommandées à des fins de validation et de surveillance :
- Validation DNS privée
- Vérifier que
*.services.ai.azure.comse résout vers des adresses IP privées depuis le jumpbox.
- Vérifier que
- Vérification de l’identité et des autorisations
- S’assurer que les rôles attribués incluent :
- Azure AI User
- Azure AI Project Manager
- Isolement régional (optionnel)
- Déployer un petit projet de test dans une autre région (par exemple, Europe Ouest) afin de confirmer le caractère régional du comportement.
Solution de contournement temporaire
- Continuer à utiliser les API Assistants pendant la stabilisation de l’orchestration des Agents.
Les références suivantes pourraient vous être utiles
- Set up private networking for Foundry Agent Service - Microsoft Foundry | Microsoft Learn
- Set up your environment for Foundry Agent Service - Microsoft Foundry | Microsoft Learn
Merci de nous indiquer si cette réponse vous a été utile.
Merci.
Si cette réponse vous a été utile, merci de voter pour elle (pouce levé) et de l'accepter comme réponse. Cela aidera les autres membres de la communauté rencontrant le même problème.