L’essentiel
Microsoft loue désormais l’environnement d’exécution d’agents qui fait tourner GitHub Copilot. Depuis le 28 octobre 2026, le harness Copilot est en préversion publique dans Foundry Agent Service : Microsoft exécute la boucle d’agent et le bac à sable, les développeurs choisissent le modèle et rédigent instructions, skills et outils. Pour les équipes qui envisagent le développement d’agents IA, cela économise des semaines de plomberie, mais lie l’exécution aux règles et aux tarifs de Microsoft.
Qu’a annoncé Microsoft ?
Un harness, c’est tout ce qui entoure le modèle et permet à un agent de mener une tâche à bien : instructions, contexte, outils, environnement d’exécution et contrôles. Dans un billet cosigné par Tina Schuchman, CVP de Foundry, et Vladimir Fedorov, CTO de GitHub, Microsoft annonce ouvrir aux développeurs externes le harness conçu par GitHub pour Copilot, soit sous forme de SDK téléchargeable, soit comme service entièrement géré dans Foundry, où Microsoft exécute la boucle d’agent et le bac à sable avec une gouvernance intégrée. Microsoft indique aussi avoir récemment porté le runtime du harness en Rust pour réduire la charge des sessions et le délai avant le premier token.
Selon The New Stack, le harness gère les appels aux modèles et aux outils, suit le contexte et maintient les agents dans le cadre des politiques configurées. Les skills regroupent instructions, scripts et ressources ; les agents peuvent manipuler des fichiers, exécuter du code et confier des tâches à des sous-agents dont l’agent principal agrège les résultats. Les agents sont définis dans un fichier azure.yaml, déployés avec azd deploy --all via l’Azure Developer CLI, et leur configuration peut être versionnée à côté du code applicatif. Une option naturelle pour les équipes déjà sur Azure.
Quels sont les compromis ?
Le principal concerne le contrôle de l’environnement d’exécution. Le type de harness doit être choisi à la création d’un agent de prompt et ne peut plus être modifié ensuite, même dans une nouvelle version. Microsoft décide aussi de la quantité de CPU et de mémoire allouée à l’agent et de la durée pendant laquelle il peut rester inactif. Les développeurs décident de ce que fait l’agent, pas de l’environnement dans lequel il tourne.
La promesse multimodèle a elle aussi ses limites. Microsoft cite plus de 20 modèles de pointe et l’option « bring your own key », mais dans la version gérée de Foundry les agents utilisent des modèles compatibles déployés via Foundry, et The New Stack précise que les modèles personnalisés ne sont pas pris en charge. Les équipes qui ont besoin de leurs propres frameworks ou modèles peuvent se tourner vers les Foundry hosted agents, pour lesquels Microsoft ne gère que l’hébergement ; le même jour, la résilience des tâches longues est devenue généralement disponible pour ces agents, ce qui permet à des tâches de plusieurs heures ou jours de reprendre après une interruption.
Combien cela va-t-il coûter ?
Le harness est gratuit dans Foundry Agent Service jusqu’au 1er décembre 2026, même si l’inférence des modèles ainsi que certains outils et services connectés sont facturés à part. Ensuite, Microsoft facturera 0,0994 $ par heure de vCPU et 0,0118 $ par heure de Gio de mémoire, avec des tarifs susceptibles de varier selon la région et le contrat. Pour la plupart des agents, le coût d’exécution reste faible face aux tokens, mais les sessions inactives, les tâches longues et les sous-agents en parallèle s’additionnent : mieux vaut suivre le coût par tâche menée à bien plutôt que par mois.
Qu’est-ce que cela signifie pour les équipes logicielles aux États-Unis et dans l’UE ?
La difficulté des agents se déplace du choix du modèle vers l’ingénierie du runtime : bac à sable, permissions des outils, relances, gestion du contexte et pistes d’audit. Un harness géré qui sert déjà des millions d’utilisateurs de Copilot, selon Microsoft, retire une bonne partie de ce travail du backlog. Pour les équipes américaines sur Azure, cela peut ramener un pilote de plusieurs semaines à quelques jours et offrir aux équipes sécurité un runtime connu à évaluer plutôt que du code maison.
Pour les équipes européennes, un runtime encadré avec des connexions MCP soumises à approbation et des contrôles de politique aide à répondre aux obligations de journalisation et de supervision humaine demandées par les clients régulés, mais ne règle pas la question du lieu de traitement des données. Vérifiez dans quelles régions tournent l’agent et le modèle, et documentez accès aux outils et approbations pour les revues RGPD, DORA et AI Act. Partout, la question stratégique est la même : plus votre agent vit dans le harness d’un fournisseur, plus il sera difficile d’en changer.
Qu’est-ce que cela signifie pour le marché français ?
En France, la question de la souveraineté pèse plus lourd qu’ailleurs dans le choix d’un runtime d’agents. Azure dispose de régions en France, mais il faut vérifier au cas par cas que la préversion et le modèle choisi y sont disponibles, et rappeler qu’un service Microsoft reste soumis au droit américain. Pour les administrations, les opérateurs d’importance vitale et les données sensibles, la référence reste la qualification SecNumCloud de l’ANSSI, que ne possède pas l’offre Azure publique : le harness Copilot convient donc mieux à des cas d’usage internes ou à des données non sensibles.
Côté conformité, les recommandations de la CNIL sur l’IA rappellent de documenter les traitements et de réaliser une analyse d’impact (AIPD) lorsqu’un agent traite des données personnelles à grande échelle ; les journaux et approbations du harness facilitent ce travail. Notre conseil pour les ESN, scale-up et DSI françaises : piloter pendant la période gratuite sur un périmètre interne bien délimité, conserver skills et évaluations dans votre propre dépôt Git et garder une option de runtime auto-hébergé ou souverain pour les données critiques.
Que faire maintenant ?
- Piloter pendant la période gratuite. Construisez un vrai agent avant le 1er décembre et mesurez taux de réussite, tokens et heures d’exécution par tâche.
- Garder la logique des agents dans votre dépôt. Stockez skills, instructions, définitions d’outils et évaluations dans Git pour pouvoir les migrer vers un autre runtime.
- Choisir le harness en amont. Comme il ne peut plus être modifié après création, tranchez entre harness Copilot et hosted agents pour chaque cas d’usage avant de construire.
- Verrouiller les outils. Utilisez l’authentification et les approbations MCP, des identifiants au moindre privilège et des bacs à sable séparés pour les données de production.
- Fixer budgets et alertes. Suivez heures de vCPU, mémoire et dépenses de modèles par agent, et plafonnez le temps d’inactivité et les sous-agents parallèles.
- Confirmer la localisation des données. Consignez régions, modèles et flux de données pour les audits clients et réglementaires.
Questions fréquentes
Qu’est-ce que le harness Microsoft Copilot ?
C’est la couche d’orchestration que GitHub a construite pour ses propres produits Copilot : la partie qui entoure le modèle et gère instructions, contexte, appels d’outils, bac à sable d’exécution et contrôles de politique. Selon Microsoft, ce même harness fait désormais tourner Copilot Code, Copilot Studio, l’application GitHub Copilot, la CLI et VS Code. Depuis le 28 octobre 2026, les développeurs peuvent l’utiliser pour leurs propres agents via Foundry Agent Service en préversion publique, ou télécharger un SDK sur GitHub.
Combien coûte le harness Copilot ?
Le harness est gratuit dans Foundry Agent Service jusqu’au 1er décembre 2026, même si l’inférence des modèles ainsi que certains outils et services connectés sont facturés à part. Ensuite, selon The New Stack, Microsoft facturera 0,0994 $ par heure de vCPU pour le calcul et 0,0118 $ par heure de Gio pour la mémoire, avec des tarifs pouvant varier selon la région et le contrat client.
Quels modèles les agents du harness Copilot peuvent-ils utiliser ?
Microsoft indique que le harness fonctionne avec plus de 20 modèles de pointe et l’option « bring your own key ». Dans la version gérée de Foundry, les agents utilisent des modèles compatibles déployés via Foundry ; The New Stack précise que les modèles personnalisés n’y sont pas pris en charge. Les équipes qui ont besoin de leurs propres modèles ou frameworks peuvent utiliser les Foundry hosted agents.
Quels sont les risques de dépendance ?
Le type de harness est choisi à la création d’un agent de prompt et ne peut plus être modifié, même dans une nouvelle version, et Microsoft fixe les limites de CPU, de mémoire et d’inactivité. Conserver skills, instructions, définitions d’outils et évaluations dans votre propre dépôt, derrière une fine interface interne, permet de garder une migration ultérieure vers un autre runtime gérable.
Faut-il construire nos agents sur le harness Copilot dès maintenant ?
Il convient bien aux pilotes, aux outils internes et aux équipes centrées sur Azure qui veulent rapidement un runtime d’agents encadré. Pour des produits durables, testez-le pendant la préversion gratuite, mesurez le coût par tâche menée à bien et comparez-le à un framework auto-hébergé avant d’y engager des charges de production.
Sources
The Official Microsoft Blog — Introducing the Microsoft Copilot harness (source primaire, 28 octobre 2026)
The New Stack — Microsoft’s new Copilot harness makes agents easy, until you want to switch (octobre 2026)
Visual Studio Magazine — Microsoft Opens GitHub-Built Copilot Harness to Developers Through Foundry (28 octobre 2026)