AIREITERChanger de modèle ne devrait pas obliger à réécrire toute l’orchestration. Pourtant, c’est exactement le genre de chantier qui fait déraper les calendriers d’un projet d’agent. Le Microsoft Copilot harness dans Microsoft Foundry apporte une réponse managée : il s’agit de la même couche d’exécution que celle utilisée par Copilot Code, Copilot Studio, l’application GitHub Copilot, la CLI et Visual Studio Code. Elle est désormais disponible en préversion publique, avec un runtime gratuit jusqu’au 1er décembre 2026 (blogs.microsoft.com). C’est le bon moment pour expérimenter, mais mieux vaut conserver votre pile actuelle en production tant que les limites de préversion détaillées plus bas ne sont pas levées.
Ce que fait réellement le Microsoft Copilot harness
Le Microsoft Copilot harness est la couche d’orchestration managée qui entoure le modèle et transforme son raisonnement en tâches menées à bien. Microsoft fournit la boucle d’agent, le bac à sable, la gouvernance et l’optimisation ; le développeur apporte les instructions, les compétences, les outils et choisit le modèle.
Microsoft résume l’idée sans détour : « Si le modèle fournit l’intelligence, le harness représente tout ce qui l’entoure » (blogs.microsoft.com). Dans les faits, le harness gère le contexte de travail au fil de l’avancement, coordonne les appels aux modèles et aux outils, exécute les fichiers et le code dans un bac à sable, délègue des sous-tâches délimitées à des sous-agents intégrés et applique les limites ainsi que les règles configurées (devblogs.microsoft.com).
| Responsabilité | Gestion par Microsoft Foundry | Ce que vous fournissez |
|---|---|---|
| Boucle d’agent et exécution en bac à sable | Oui | Non |
| Gouvernance, validations et optimisation | Oui | Configuration |
| Instructions et compétences | Non | Oui |
| Outils, serveurs MCP et connaissances | Non | Oui, avec l’authentification que vous configurez |
| Choix du modèle | Liste prise en charge | Votre choix de déploiement |
Un routage multi-modèle avec plus de 20 modèles de pointe et le BYOK
Le Microsoft Copilot harness prend en charge plus de 20 modèles de pointe issus de différentes familles, avec des configurations bring-your-own-key (BYOK), puis achemine chaque tâche vers le ou les modèles appropriés (blogs.microsoft.com). Microsoft ne publie pas la liste complète des 20 modèles dans son annonce. Vérifiez donc leur disponibilité exacte dans votre région Foundry avant de concevoir une architecture multi-modèle. La promesse est simple : les clients n’ont plus à maintenir leur propre routeur. « Vous apportez les instructions, les compétences, les outils et le choix du modèle. »
Un premier développeur résume ainsi l’intérêt du dispositif : ne plus devoir réécrire la couche d’orchestration chaque fois que le modèle change — @ai_fengshou.
Un runtime Rust déjà au cœur de plusieurs produits
Le runtime du Microsoft Copilot harness a récemment été porté vers Rust. Selon Microsoft, cette migration a réduit la surcharge des sessions et le délai avant le premier token (blogs.microsoft.com). Aucun gain en pourcentage ni tableau de latence n’ayant été publié, il faut considérer cette affirmation comme une tendance générale, pas comme une mesure de référence.
Microsoft indique que ce même harness fait déjà fonctionner Copilot Code, Copilot Studio, l’application GitHub Copilot, la CLI GitHub Copilot, Visual Studio Code ainsi que d’autres surfaces Copilot de Microsoft et GitHub (blogs.microsoft.com). L’éditeur présente cette base commune comme éprouvée auprès de millions d’utilisateurs et dans des centaines de cas d’usage réels (blogs.microsoft.com).
Le harness reste extensible grâce au Model Context Protocol (MCP), aux compétences d’agent et aux plug-ins d’agent (blogs.microsoft.com).
Ce qui a changé le 28 octobre 2026
Le 28 octobre 2026, Microsoft a annoncé deux évolutions liées : le Microsoft Copilot harness est entré en préversion publique dans Foundry Agent Service, tandis que la résilience des agents hébergés sur les traitements de longue durée est devenue généralement disponible (devblogs.microsoft.com).
La terminologie évolue elle aussi. Dans la documentation de Copilot Studio, on parle encore parfois du GitHub Copilot harness, mais le nom Microsoft Copilot harness s’impose désormais dans les produits. Les différentes pages ne sont simplement pas mises à jour au même rythme (microsoft.com).
Foundry Agent Service propose désormais trois niveaux d’abstraction : les agents basés sur un prompt, sans harness ; les agents basés sur un prompt avec le Microsoft Copilot harness, en préversion ; et les agents hébergés, pour lesquels le développeur contrôle le framework (devblogs.microsoft.com). La résilience des traitements longs — la capacité d’un agent hébergé à reprendre son travail après une interruption au cours de workflows durant des heures ou des jours — est la fonctionnalité déjà disponible en GA.
Construire un agent avec harness dans Foundry
Un agent Foundry utilisant le harness se définit de manière déclarative et est stocké avec le code de l’application (devblogs.microsoft.com). Les développeurs le créent et le testent dans Foundry, conservent sa définition dans le contrôle de version, puis le déploient avec Azure Developer CLI (azd) ou depuis le portail Foundry (devblogs.microsoft.com).
Les compétences réutilisables encapsulent la méthode
Les compétences réutilisables regroupent les instructions, scripts, ressources complémentaires et procédures qu’un agent peut appliquer à différents travaux. Dans l’exemple documenté, la compétence research-brief, située dans skills/research-brief/SKILL.md, oblige l’agent à confirmer la question, le public visé, le périmètre et la période étudiée, à recueillir des éléments avec les outils approuvés, à citer les sources et les dates, à distinguer les faits de l’interprétation et à signaler les éléments contradictoires.
Les outils connectés restent soumis à la gouvernance
Les outils connectés permettent aux agents d’utiliser les outils Microsoft Foundry et les outils MCP avec une authentification et des validations explicitement configurées. Cette étape de validation constitue un garde-fou de gouvernance. Comme le montrent les retours Reddit ci-dessous, elle peut aussi devenir une source de friction en production lorsque les utilisateurs finaux doivent accepter plusieurs fois les mêmes demandes d’autorisation.
Exécution, fichiers et délégation
Les agents manipulent des fichiers, exécutent du code et délèguent des tâches délimitées à des sous-agents intégrés, tandis que l’agent principal coordonne les résultats. La comparaison des harnesses dans Copilot Studio précise que le harness issu de GitHub crée et modifie nativement des fichiers Word, Excel, PowerPoint et PDF, tout en prenant en charge les compétences et la mémoire (learn.microsoft.com).
Des définitions versionnées et un indicateur de harness sur une ligne
Les définitions des agents vivent aux côtés du code. L’exemple Foundry déclare le harness dans azure.yaml (devblogs.microsoft.com) :
harness:
type: microsoft_copilot_previewL’exemple relie un agent basé sur le prompt research-brief à une compétence research-brief-skill, avec la recherche web (public-research) et Code Interpreter (research-analysis). Les variables FOUNDRY_PROJECT_ENDPOINT et MODEL_DEPLOYMENT_NAME servent de paramètres d’environnement (devblogs.microsoft.com). Le déploiement et l’appel s’effectuent avec la CLI en préversion :
azd deploy --all
azd ai agent invoke research-brief \
"Compare publicly announced approaches to agent interoperability. Produce a concise brief with sources, tradeoffs, and open questions."Il est également possible de créer l’agent depuis le portail Foundry, le Foundry Toolkit pour Visual Studio Code ou le plug-in Foundry pour l’application GitHub Copilot (devblogs.microsoft.com).
Quelle architecture d’agent Foundry choisir ?
Il n’existe pas un niveau d’abstraction idéal pour tous les projets. La recommandation de Microsoft consiste à choisir le niveau qui réduit au minimum l’infrastructure à prendre en charge tout en répondant aux besoins de l’application (devblogs.microsoft.com). Pendant la préversion, ce choix est définitif dès la création de l’agent : mieux vaut donc le faire avant de cliquer sur « Créer ».
| Approche | À privilégier quand | Ce que vous gagnez | Ce que vous abandonnez |
|---|---|---|---|
| Agent basé sur un prompt sans harness | Les instructions et les outils pris en charge suffisent | La solution la plus simple, avec le moins de responsabilités | Pas de compétences, de gestion des fichiers, de sous-agents ni d’orchestration avancée |
| Agent basé sur un prompt avec le Microsoft Copilot harness (préversion) | Vous avez besoin de compétences, d’une exécution managée, de fichiers, de sous-agents ou d’une coordination complexe des outils | Boucle et bac à sable managés, compétences réutilisables et exécution plus riche | Les limites de préversion s’appliquent ; Microsoft contrôle davantage le runtime ; modèles, outils et régions pris en charge obligatoires |
| Agent hébergé | Vous devez apporter ou modifier le framework, la boucle, le middleware ou les dépendances | Un contrôle maximal avec un hébergement géré par Foundry | Vous prenez en charge les points de reprise, la logique de reprise et la prévention des actions en double |
Parmi les premiers retours clients cités par Microsoft, Confluence Technologies affirme avoir livré une solution en moins d’une semaine en se concentrant sur la conception plutôt que sur l’infrastructure. Fashable utilise de son côté le harness dans des workflows d’approvisionnement gouvernés, tout en conservant les décisions commerciales engageantes sous contrôle humain (devblogs.microsoft.com).
Combien coûtera le service après le 1er décembre 2026 ?
La facturation du runtime du Microsoft Copilot harness commencera le 1er décembre 2026, selon un modèle à la consommation. L’utilisation du runtime restera gratuite avant cette date, mais l’inférence des modèles, les outils facturés séparément et les services connectés seront facturés à part pendant toute la période.
| Ressource du bac à sable | Tarif à partir du 1er décembre 2026 |
|---|---|
| Calcul du bac à sable | $0.0994 par vCPU-heure |
| Mémoire du bac à sable | $0.0118 par GiB-heure |
Les tarifs peuvent varier selon la région et l’accord commercial du client (devblogs.microsoft.com). Pendant la préversion, Foundry gère le processeur, la mémoire et les paramètres d’inactivité de l’environnement d’exécution (devblogs.microsoft.com), et renvoie vers une documentation distincte pour les régions, modèles, outils et limites de préversion pris en charge.
Dans Copilot Studio, les agents reposant sur le harness issu de GitHub sont facturés via les Copilot Credits selon un modèle à l’usage, sur une surface de facturation distincte du décompte du bac à sable Foundry (learn.microsoft.com). Pour estimer un pilote, multipliez le nombre observé de vCPU-heures et de GiB-heures du bac à sable par les tarifs ci-dessus, puis ajoutez les coûts des tokens de modèle et des outils.
Les limites de la préversion à vérifier avant de commencer
C’est souvent dans les petites lignes qu’un pilote de préversion montre s’il peut survivre au passage en production. Les contraintes suivantes proviennent de la publication Foundry de Microsoft, sauf lorsqu’elles sont explicitement présentées comme des observations d’utilisateurs.
- Le choix du harness est pour l’instant irréversible. Sélectionnez le harness au moment de créer l’agent : les agents existants ne changent pas et il n’est pas encore possible de changer de harness après la création. Un premier lecteur a précisément relevé ce point : « vous choisissez le Copilot harness lors de la création de l’agent. Les agents existants restent inchangés et le changement de harness après la création n’est pas encore pris en charge » — @navaneethan_es.
- Les régions et les modèles sont limités. Foundry renvoie vers sa documentation pour la liste complète des régions, modèles, outils et limites de préversion pris en charge. Selon le résumé d’un utilisateur, environ neuf régions seraient disponibles, sans couverture du Moyen-Orient et sans prise en charge complète du bring-your-own-model — @HeshamSaadZaki. Il s’agit d’une lecture utilisateur à vérifier dans la documentation, pas d’un tableau officiel des régions.
- La reprise des traitements longs reste à votre charge. Foundry redémarre le travail hébergé interrompu et lui transmet à nouveau l’entrée initiale, mais l’application doit enregistrer sa progression, reprendre depuis des points de contrôle et empêcher les actions en double, comme la création deux fois du même rapport externe. L’historique d’une conversation ne suffit pas à restaurer un travail en cours.
- Aucun chiffre de benchmark ou de SLA n’accompagne le lancement. Il faut s’attendre à des affirmations qualitatives comme « des performances de pointe » sans tableau de latence, de débit ou de précision.
Les premiers utilisateurs du Copilot harness face à la production
Les utilisateurs de Copilot Studio qui travaillent avec le harness issu de GitHub signalent plusieurs problèmes récurrents autour de la frontière entre préversion et production. Ces témoignages décrivent l’expérience du GitHub harness dans Copilot Studio avant la préversion Foundry. Ils sont repris ici comme un indice lié à la filiation commune décrite par Microsoft (blogs.microsoft.com), et non comme des mesures réalisées dans Foundry.
Les connecteurs ne restent même pas connectés une journée en production. — u/roberts2727 dans r/copilotstudio
Parfois les flux fonctionnent ; d’autres fois, l’agent ne leur transmet absolument rien. — u/donstazz dans r/copilotstudio
Les utilisateurs métier ne peuvent pas gérer ces enregistrements d’applications, etc. Ce sont les administrateurs IT qui doivent s’en charger, pour chaque agent séparément. — u/Teemu_St dans r/copilotstudio
Les problèmes rapportés dans ces discussions comprennent :
- Des réponses plus lentes sur les agents adossés à SharePoint, décrites comme nettement plus lentes que celles d’autres solutions dans r/copilotstudio.
- Des agents qui fonctionnent dans le volet de test de Studio, mais échouent après leur déploiement dans Teams ou M365 Copilot avec des erreurs génériques, selon r/copilotstudio.
- Une instabilité des connecteurs et des flux, ainsi que des demandes répétées d’authentification et de consentement MCP, d’après r/copilotstudio.
- Une confusion sur la facturation : une licence M365 Copilot couvre-t-elle le runtime du harness ou les Copilot Credits s’appliquent-ils malgré tout ? La question est discutée dans r/microsoft_365_copilot.
Ces retours ne remettent pas en cause la préversion Foundry. Ils imposent en revanche une vraie checklist de pilote : testez votre source de connaissances réelle, votre canal réel et le parcours de consentement effectivement utilisé par vos utilisateurs avant de promettre un calendrier.
FAQ
Le Microsoft Copilot harness est-il le même que le GitHub Copilot harness ?
Oui. Il s’agit de la même lignée développée à partir de GitHub, désormais commercialisée sous le nom Microsoft. Certaines pages de Copilot Studio utilisent encore l’ancienne appellation pendant la transition.
Quels modèles le harness Foundry prend-il en charge ?
Plus de 20 modèles de pointe, ainsi que le BYOK avec un routage adapté à la tâche. Microsoft ne publie pas la liste complète : consultez donc la documentation Foundry correspondant à votre région, comme indiqué dans la section consacrée au multi-modèle.
Puis-je migrer un agent Foundry existant vers le harness ?
Non, pas par simple changement sur place pendant la préversion. Menez plutôt une évaluation en parallèle : recensez les prompts, outils, autorisations et besoins d’état, recréez l’agent avec microsoft_copilot_preview dans un projet de préversion, puis comparez la qualité, la latence, la consommation du bac à sable et la reprise avant de basculer.
Une licence M365 Copilot couvre-t-elle l’utilisation du harness ?
Pas automatiquement. Foundry mesure séparément le calcul et la mémoire du bac à sable, ainsi que l’inférence des modèles, tandis que Copilot Studio facture cette famille de harnesses via les Copilot Credits. Vérifiez le compteur applicable à votre surface.
Dois-je choisir le harness ou un agent hébergé ?
Choisissez le harness si vous voulez une boucle managée, un bac à sable, des compétences et des sous-agents sans prendre en charge l’orchestration. Préférez un agent hébergé si vous devez contrôler le framework ou le runtime et que vous pouvez gérer les points de contrôle ainsi que l’idempotence.
Commencez par le modèle de compétence research-brief en préversion, mesurez le coût du bac à sable et des tokens par rapport à celui d’un agent basé sur un prompt sans harness pour la même tâche, et gardez la production sur votre architecture éprouvée tant que la migration, les régions et le comportement du consentement ne sont pas documentés pour votre tenant.