Avant Microsoft Build 2027, comment valider le déploiement de Foundry Hosted Agents ?

Votre agent est déployé, mais vous ne savez pas encore si son état de préparation ou ses réponses de session sont fiables.

La réponse rapide : ne validez pas la mise en service sur le seul statut « déployé ». Vérifiez aussi le protocole d’exécution, le contrôle de disponibilité, l’identité, les échanges avec état et les appels effectués après la publication. Microsoft Foundry peut héberger un agent de code sous forme d’application conteneurisée ; le code, le comportement du protocole et les tests applicatifs restent à votre charge (présentation de Foundry Hosted Agents).

Vous migrez un agent local vers un environnement hébergé ? Les contrôles de cet article vous aideront à organiser les essais avant et après publication.
Vous gérez l’environnement ou le processus de livraison ? Vous pourrez vérifier le conteneur, l’état de préparation et la transition entre versions.
Vous préparez votre infrastructure d’agents avant Microsoft Build 2027 ? Utilisez ce parcours pour éprouver l’existant, sans présumer d’annonces ni de fonctionnalités futures.

Avant la publication : cadrer les dépendances

Un environnement d’exécution d’agent IA hébergé convient surtout lorsque votre application peut être empaquetée et qu’elle reçoit ses demandes par le protocole documenté. Cela ne signifie pas que toutes les applications locales sont prêtes à être hébergées. Commencez par inventorier ce que le processus suppose : fichiers présents sur la machine, accès réseau, variables de configuration, secrets, stockage persistant, services externes et tâches exécutées en arrière-plan.

La documentation Microsoft décrit Hosted Agents comme un moyen de déployer des agents fondés sur du code dans une infrastructure gérée, avec un contrat d’exécution et des parcours de déploiement associés. Elle délimite les capacités de la plateforme ; elle ne certifie pas que votre programme est portable sans modification. Consultez la présentation officielle de l’hébergement et le guide de déploiement de votre propre code pour confronter vos hypothèses aux options décrites.

Distinguez les dépendances de construction de celles nécessaires à l’exécution. Une bibliothèque absente du paquet peut empêcher le démarrage. Un fichier supposé être écrit dans un répertoire local peut fonctionner pendant un essai et disparaître ou devenir inaccessible dans le contexte hébergé. De même, une intégration qui repose sur un accès réseau ouvert peut échouer si la configuration de l’environnement ne l’autorise pas. Ne remplacez pas ces vérifications par une estimation de configuration : les ressources disponibles dépendent du service et des paramètres effectivement proposés à votre déploiement.

Préparez un projet reproductible : code source, fichiers de dépendances, instructions de construction, configuration non secrète et données d’essai. Gardez les secrets en dehors du paquet et vérifiez comment l’identité et les autorisations sont configurées dans votre parcours de publication. Pour une application Python comme pour un service .NET, consignez les versions que vous avez choisies et la commande réellement utilisée pour construire et lancer l’application. Ce sont les résultats observés dans votre propre projet qui feront foi.

Que faut-il contrôler avant de lancer le déploiement ? Vérifiez que le projet peut être construit à partir d’un état propre, que les dépendances sont déclarées et que l’application n’attend pas un fichier ou un service local absent de l’environnement cible. Ensuite, repérez les échanges externes indispensables et l’identité qui les autorisera.

Un inventaire pratique peut prendre cette forme :

• [ ] Le paquet contient le code et les dépendances nécessaires au démarrage.
• [ ] Les paramètres propres à l’environnement sont séparés du code.
• [ ] Les secrets ne sont pas enregistrés dans les fichiers distribués.
• [ ] Les accès aux services externes ont un propriétaire et des autorisations identifiés.
• [ ] Les fichiers nécessaires après le démarrage ne dépendent pas d’un stockage local supposé persistant.
• [ ] Le contrat d’exécution choisi correspond à la façon dont l’application reçoit ses demandes.

En local : éprouver le contrat avant l’hébergement

Le contrat d’exécution n’est pas une garantie que votre agent traite correctement chaque entrée. C’est le cadre que l’application doit respecter pour communiquer avec le service hébergeant l’agent. Lisez le contrat officiel d’exécution des Hosted Agents, puis comparez-le à votre code, au point d’entrée réellement lancé et à la configuration de votre projet.

Ne recopiez pas un exemple de commande trouvé dans un ancien tutoriel sans vérifier qu’il correspond à la documentation actuelle. Les méthodes de publication, les noms de paramètres et les versions de SDK peuvent évoluer. La documentation actuelle de déploiement doit rester la référence au moment où vous préparez votre livraison. Votre objectif local est de prouver le comportement de votre application, pas de reproduire à l’identique l’infrastructure hébergée.

Testez au moins trois chemins fonctionnels : une demande valide, une entrée mal formée ou incomplète, et une erreur provenant d’une dépendance externe. Pour chacun, vérifiez ce que reçoit l’application, ce qu’elle renvoie et si l’erreur est signalée de façon exploitable. Si votre agent produit une réponse en continu, observez le début, la progression et la fin de cette réponse ; ne concluez pas que le flux est correct parce qu’une réponse complète fonctionne. Si le protocole choisi prévoit un format ou des événements particuliers, comparez la sortie réelle aux exigences de ce contrat.

La même prudence s’applique aux sessions. Effectuez deux demandes dans une même session, puis une autre dans un contexte indépendant. Vérifiez quelles informations sont conservées, lesquelles ne le sont pas et si l’application dépend d’un état stocké uniquement dans la mémoire du processus. Cette distinction est essentielle quand un agent mène une tâche en plusieurs étapes, par exemple l’analyse d’un scénario vidéo, la préparation d’un montage audio ou l’itération sur une proposition de design. Une réponse correcte isolément ne prouve pas que l’état du travail est correctement géré.

Comment vérifier la disponibilité et le protocole de requête ? Comparez le contrôle de disponibilité configuré avec le comportement réel du processus : un démarrage réussi ne suffit pas si le service ne peut pas encore traiter les demandes. Vérifiez ensuite que votre application accepte la requête dans le format attendu et répond selon le contrat choisi. N’inventez ni route ni format universel : utilisez ceux indiqués pour votre méthode de déploiement et votre implémentation dans la documentation du contrat.

Pendant la publication : suivre le chemin choisi

Le déroulement exact dépend de la méthode de publication documentée pour votre projet. Certaines étapes peuvent varier selon le parcours retenu ; vérifiez leur nom et leur ordre dans le guide Microsoft de déploiement des agents hébergés. Ne transformez pas un exemple de documentation en procédure universelle et ne considérez pas ses valeurs d’exemple comme la configuration de votre équipe.

Dans les grandes lignes, préparez le paquet, créez ou sélectionnez la version correspondant au code vérifié, lancez le déploiement, puis attendez que la plateforme indique l’état prévu avant d’essayer l’agent. Notez l’identifiant de version ou tout autre repère que le parcours documenté met à votre disposition. Conservez également le lien entre cette version et le commit ou l’artefact source : sans cette traçabilité, un échec après publication sera plus difficile à attribuer au code, au paquet ou à la configuration.

Ne confondez pas quatre notions : la demande de publication a été envoyée, la création de la version est terminée, le service considère l’agent prêt, et un client peut effectivement l’appeler. Un statut intermédiaire n’est pas la preuve que le dernier maillon fonctionne. À chaque transition, vérifiez le résultat indiqué par le portail ou l’outil employé, puis faites un appel représentatif depuis le chemin de consommation prévu.

Où commencer si la publication échoue ? Repérez d’abord l’étape qui n’aboutit pas : construction du paquet, création de version, attente de disponibilité ou premier appel. Puis examinez le message associé et les journaux au lieu de relancer aveuglément le même déploiement. Le guide officiel de débogage aide à orienter l’analyse vers les erreurs de l’agent hébergé ; rapprochez ses indications des journaux de votre application.

Après la publication : valider identité, état et appels

L’essai décisif se fait au moyen du chemin réel qu’utilisera votre application cliente. Lancez une requête réussie, une requête qui doit échouer de manière contrôlée, puis une courte séquence de demandes liées à une session. Pour chaque appel, vérifiez que l’identité utilisée est celle prévue, que les autorisations correspondent à la ressource sollicitée et que la réponse observée correspond au cas testé. Ne déduisez pas la réussite d’une intégration du seul fait que l’agent apparaît dans la liste des déploiements.

En cas de refus d’accès, distinguez l’identité de l’appelant de celle que l’agent emploie pour joindre ses dépendances, si votre configuration mobilise ces deux rôles. Confirmez quelle identité est active pour chaque opération et quelles autorisations lui sont accordées. Évitez de résoudre un refus en élargissant les droits sans comprendre la ressource et l’action concernées : une permission excessive peut masquer une erreur de configuration et compliquer les audits.

Pour l’état de session, établissez une attente explicite avant le test. Si l’agent doit retenir un élément de contexte entre des demandes liées, vérifiez ce comportement dans le parcours réel. Si les sessions doivent rester indépendantes, vérifiez qu’aucun contenu précédent ne réapparaît. Si l’agent produit des travaux créatifs — pistes audio, descriptions de séquences vidéo ou propositions de mise en page — contrôlez également que les références et résultats associés sont rattachés au bon échange, au lieu de supposer que la plateforme conserve automatiquement l’ensemble de votre état applicatif.

Consignez l’entrée de test, le résultat attendu, la réponse reçue et l’identifiant de version. Supprimez ou masquez les données sensibles avant de conserver des traces. Pour suivre les appels et leur contexte, configurez l’observabilité selon la documentation de traçage des agents. Pour consulter les événements et journaux disponibles côté hébergement, suivez le guide de surveillance des journaux des Hosted Agents. Ces outils aident à enquêter ; ils ne remplacent pas vos critères de réussite applicatifs.

Comment confirmer qu’une session fonctionne après le déploiement ? Utilisez une séquence dont vous connaissez le résultat attendu, puis comparez les réponses et le contexte entre appels. Recommencez avec une session distincte. Si le comportement change, vérifiez d’abord la gestion d’état de votre application et les informations transmises par le client ; ne supposez pas qu’un statut de déploiement révèle la cause.

Première semaine : surveiller et décider de l’extension

Pendant la première semaine de mise en service, choisissez des observations adaptées à votre charge et à votre niveau de risque. Ce sont des indicateurs définis par votre équipe, pas des garanties de performance annoncées par Microsoft. Suivez les catégories d’échec, les tentatives de reprise, les anomalies de session, les refus d’accès et les changements de version. Relevez les conditions de chaque incident afin de distinguer un défaut reproductible d’un problème ponctuel lié à une dépendance ou à une configuration.

Avant d’élargir le pilote, décidez qui peut arrêter la diffusion, quelle version est la référence connue comme fonctionnelle et comment revenir à un état antérieur selon les possibilités du processus de livraison que vous utilisez. Vérifiez ce chemin de retour avant d’en avoir besoin : une stratégie de retour non testée n’est qu’une intention. Après une correction, rejouez les cas qui ont échoué et ceux qui pourraient être affectés par le changement.

Votre bilan peut rester simple, à condition d’être vérifiable :

• [ ] La version évaluée est reliée au code et au paquet publiés.
• [ ] Les appels réussis et les erreurs contrôlées ont été testés depuis le client prévu.
• [ ] Les sessions liées et indépendantes ont donné les résultats attendus.
• [ ] L’identité et les autorisations ont été vérifiées pour les appels pertinents.
• [ ] Les erreurs peuvent être rapprochées des traces ou journaux disponibles.
• [ ] Les reprises et les anomalies récurrentes sont classées par cause probable.
• [ ] Une personne responsable sait suspendre l’essai et appliquer le retour prévu.
• [ ] L’extension du pilote dépend de résultats observés, pas du seul état « prêt ».

Si un de ces contrôles essentiels reste incertain, corrigez le problème avant d’augmenter le nombre d’utilisateurs ou de tâches confiées à l’agent. Si les tests sont reproductibles, que les incidents sont compris et que le retour arrière est praticable, vous pouvez étendre progressivement le périmètre en conservant les mêmes critères d’observation.

Un hébergement géré peut réduire le travail d’exploitation de l’infrastructure, mais il ne rend pas l’application autonome : vous devez encore maintenir le paquet, corriger le protocole, configurer les accès et examiner les incidents. À l’inverse, une machine que vous administrez directement peut offrir davantage de contrôle, mais vous laisse aussi davantage de tâches d’installation, de mise à jour et de surveillance. Pour un besoin temporaire de ressources distantes afin de tester un agent, comparer des versions ou exécuter un pilote, examinez les conditions d’accès et de livraison indiquées dans les détails des services Hashvps ; ce choix ne remplace pas la validation de Foundry et n’est pas nécessaire si votre environnement actuel répond déjà au besoin. Si un point opérationnel de l’offre reste à clarifier, vous pouvez aussi consulter le centre d’aide Hashvps.