Microsoft rend l’environnement d’orchestration Copilot accessible via Foundry

Le 28 octobre 2026, Microsoft a rendu l’environnement d’orchestration Microsoft Copilot — la couche d’orchestration multimodèle qui alimente déjà Copilot Code, Copilot Studio, l’application GitHub Copilot, la CLI Copilot et VS Code — accessible aux développeurs et aux entreprises via Microsoft Foundry, dans une annonce publiée sur le blog officiel de Microsoft.

Microsoft décrit un environnement d’orchestration comme tout ce qui entoure le modèle : la couche d’orchestration qui fournit à un agent les bonnes instructions, le contexte, l’environnement d’exécution et les contrôles nécessaires pour accomplir ses tâches, avec la prise en charge de normes ouvertes telles que le Model Context Protocol, ainsi que des compétences d’agent et des extensions d’agent. L’équipe d’ingénierie de GitHub a créé l’environnement d’orchestration Copilot, que Microsoft a adopté dans l’ensemble de l’entreprise. Un article complémentaire publié le même jour sur le blog Microsoft Foundry a présenté cet environnement dans Foundry Agent Service en préversion publique et annoncé la disponibilité générale de la résilience pour les agents hébergés exécutés sur de longues durées.

Microsoft a indiqué que cet environnement d’orchestration est conçu pour fonctionner avec différentes familles de modèles, qu’il prend en charge plus de 20 modèles de pointe ainsi que la possibilité d’utiliser sa propre clé, et qu’il oriente les tâches vers le ou les modèles les mieux adaptés en fonction de la tâche. L’entreprise a précisé qu’il exécute la boucle de l’agent et le bac à sable, avec des fonctions intégrées de gouvernance et d’optimisation, tandis que les clients fournissent les instructions, les compétences, les outils et le modèle de leur choix. Le SDK Copilot est disponible au téléchargement, et l’environnement d’orchestration peut également s’exécuter dans le cloud géré par Foundry ; Microsoft a indiqué que ses plateformes restent ouvertes à d’autres environnements d’orchestration et frameworks.

Exécution gérée dans Foundry Agent Service

Selon l’article du blog Foundry, la préversion publique réunit quatre composants. Les compétences réutilisables regroupent des instructions, des scripts et des ressources complémentaires en procédures qu’un agent peut appliquer à différentes tâches. Les outils connectés comprennent les outils pris en charge par Foundry et ceux du Model Context Protocol, avec une authentification et des autorisations explicitement configurées. L’exécution et la délégation permettent aux agents de travailler sur des fichiers et du code, et de confier des tâches délimitées à des sous-agents intégrés, tandis que l’agent principal coordonne le résultat. Les définitions des agents gérées dans le contrôle de version peuvent être administrées avec le code de l’application. L’environnement d’orchestration gère le contexte de travail à mesure que les tâches évoluent et coordonne les étapes faisant intervenir les modèles et les outils dans les limites et le cadre des règles définis ; les clients peuvent choisir un modèle Foundry pris en charge sans avoir à réécrire la couche d’orchestration.

Les développeurs peuvent créer des agents à l’aide de la version préliminaire de l’interface Azure Developer CLI (azd), du portail Foundry, de la boîte à outils Foundry pour Visual Studio Code, ou du plugin et de la compétence Microsoft Foundry dans l’application GitHub Copilot. L’article rapporte les propos de deux entreprises. Chris Evans, directeur technique de Confluence Technologies, a déclaré que son équipe avait mis une solution en place en moins d’une semaine, ce qui lui avait permis de se concentrer sur la conception et les fonctionnalités plutôt que sur l’infrastructure sous-jacente. Orlando Ribas Fernandes, PDG de Fashable, a indiqué que cet environnement d’orchestration fournit à l’entreprise une base pour transformer des processus complexes d’approvisionnement en flux de travail agentiques encadrés et mesurables, tout en maintenant sous contrôle humain les décisions ayant une portée commerciale contraignante.

Limites de la préversion et facturation à partir de décembre

Pendant la préversion, les clients sélectionnent l’environnement d’orchestration Microsoft Copilot lors de la création d’un agent. Les agents existants restent inchangés, il n’est pas encore possible de changer d’environnement d’orchestration après la création de l’agent, et Foundry gère le processeur, la mémoire et les paramètres d’inactivité de l’environnement d’exécution.

La facturation de l’environnement d’orchestration Copilot dans Foundry Agent Service commencera le 1er décembre 2026 et sera basée sur la consommation. L’exécution de l’environnement d’orchestration est gratuite avant cette date, tandis que l’inférence des modèles et les outils et services connectés facturés séparément restent soumis aux tarifs qui leur sont applicables. À partir du 1er décembre, le calcul dans le bac à sable sera facturé 0,0994 $ par heure de vCPU et la mémoire, 0,0118 $ par heure de GiB ; les prix varient selon la région et l’accord.

L’article présente également trois approches dans Foundry Agent Service : les agents à invites, sans l’environnement d’orchestration, lorsque les instructions et les outils pris en charge suffisent pour la tâche ; les agents à invites avec l’environnement d’orchestration Copilot, pour une exécution gérée avec des compétences, des fichiers et des sous-agents ; et les agents hébergés, lorsque les équipes ont besoin de leur propre framework, boucle d’agent, intergiciel, dépendances ou comportement d’exécution, tout en conservant un hébergement géré par Foundry.

Résilience des agents hébergés exécutés sur de longues durées

La résilience des agents hébergés exécutés sur de longues durées est désormais disponible de manière générale. Elle vise les tâches qui prennent des heures ou des jours. Foundry détecte les interruptions et relance le travail avec les données d’entrée d’origine, tandis que le code du client enregistre la progression et les résultats intermédiaires afin que l’agent puisse reprendre là où il s’était arrêté. Lorsqu’un agent met à jour un autre système, le flux de travail doit également empêcher la répétition d’actions au redémarrage. Microsoft a souligné que l’historique de conversation ne suffit pas à lui seul pour restaurer un travail en cours.

Créé chez GitHub

Microsoft a indiqué que le système avait été conçu par les mêmes ingénieurs de GitHub qui ont mené ses travaux d’orchestration multi-modèles, et qu’elle harmonisait ses expériences Copilot sur cette base. Le 4 septembre 2026, GitHub a présenté Project HydraFusion, une préversion de recherche qui élabore un plan d’exécution faisant appel à des modèles de plusieurs fournisseurs selon trois approches : le mode direct, où un seul modèle traite la tâche ; le mode en cascade, où un modèle efficace rédige une solution, puis un contrôle qualité décide s’il faut faire appel à un modèle plus puissant ; et le mode critique, où un évaluateur indépendant, en lecture seule et issu d’une autre famille de modèles, examine une première version avant que le modèle rédacteur ne la révise. GitHub a indiqué que, lors d’évaluations hors ligne, HydraFusion avait amélioré de 4,9 points de pourcentage la qualité vérifiée des tâches, pour un coût estimé inférieur de 67 % à celui de Claude Opus 5 sur TerminalBench 2.1 ; obtenu un résultat à 1,5 point près sur DeepSWE, pour un coût inférieur de 36 % ; et obtenu un résultat à 0,1 point près sur son test interne CheckpointBench, pour un coût inférieur de 65 %.

GitHub avait également révélé, le 16 septembre 2026, avoir porté sur place l’environnement d’exécution de l’agent Copilot de TypeScript vers Rust : au 21 août 2026, le code de production en Rust comptait 832 378 lignes, réparties entre 128 demandes de fusion déployées progressivement, et le SDK Copilot exposait l’environnement d’exécution à six interfaces en langage. Microsoft attribue à ce portage des performances de premier plan dans le secteur ainsi que la réduction de la surcharge des sessions et du délai avant le premier jeton. Dans des tests réalisés par Stephen Toub, ingénieur distingué chez Microsoft, au moyen du SDK C#, le temps nécessaire pour créer un client et une session, puis effectuer un tour, est passé de 5,25 secondes avant le portage à 292 millisecondes avec l’environnement d’exécution Rust chargé dans le processus ; dans un lot de dix clients, le pic de mémoire supplémentaire est passé de 1 383 Mo à 126 Mo.