Changer de modèle sans reconstruire toute la chaîne d’exécution devient un choix d’architecture crédible avec le Copilot harness. Dans Microsoft Foundry, cette souplesse reste toutefois en préversion publique et impose de nouvelles règles sur les versions, les flux de données et la traçabilité attendue pour la Loi 25.
Le harness sépare le modèle du système d’agent
Un modèle fournit les capacités de raisonnement. Le harness orchestre ce qui lui permet d’agir : instructions, contexte, appels d’outils, boucle d’agent, environnement d’exécution et contrôles opérationnels.
Cette séparation réduit la dépendance entre un agent et une famille de modèles. Une équipe peut évaluer un modèle différent sans réécrire systématiquement les outils, les skills ou l’application qui consomme l’agent. Le bénéfice attendu n’est donc pas seulement la performance du modèle, mais la stabilité de l’architecture autour de celui-ci.
Microsoft présente ce socle comme commun à plusieurs expériences Copilot et GitHub. Cette convergence facilite la mutualisation des améliorations, mais ne signifie pas que chaque produit propose les mêmes modèles, options ou statuts de disponibilité. La cartographie de l’écosystème Microsoft Copilot aide à distinguer ces différentes surfaces.
Dans Microsoft Foundry, anciennement Azure AI Foundry, le Copilot harness reste un agent prompt reposant sur l’API Responses. Foundry prend en charge l’environnement d’exécution, la boucle d’agent et le sandbox. L’équipe conserve la responsabilité des instructions, des outils, des connexions, des skills et du modèle sélectionné.
La préversion impose des décisions irréversibles
L’annonce technique de Microsoft Foundry confirme que le Copilot harness est en préversion publique. Il se sélectionne lors de la création d’un agent prompt. Les agents existants ne sont pas convertis automatiquement.
Le choix du harness est figé à la création
Le calendrier distingue trois évolutions qu’il ne faut pas confondre :
Septembre 2026
Résilience longue durée en préversion
La reprise des travaux interrompus pour les hosted agents était encore en préversion publique.
Octobre 2026
Copilot harness en préversion publique
Le harness devient sélectionnable dans Foundry Agent Service. La résilience longue durée des hosted agents passe séparément en disponibilité générale.
1er décembre 2026
Début de la facturation du harness
Le calcul et la mémoire du sandbox deviennent facturés à la consommation. L’inférence des modèles et les outils payants restent facturés séparément.
L’exécution du harness est gratuite jusqu’au 1er décembre 2026. Après cette date, Microsoft annonce les tarifs suivants :
0,0994 USD
par vCPU-heure pour le calcul du sandbox
Microsoft Foundry
0,0118 USD
par GiB-heure pour la mémoire du sandbox
Microsoft Foundry
Un calcul de coût doit donc additionner le sandbox, l’inférence et les outils éventuellement facturés. Un pilote réalisé avant le 1er décembre 2026 ne reflétera pas à lui seul le coût récurrent.
Trois architectures d’agents à comparer
Le Copilot harness n’est pas l’unique option proposée par l’écosystème Foundry. Le bon choix dépend du niveau de contrôle recherché, de la capacité de l’équipe à maintenir une boucle d’agent et des contraintes imposées au modèle.
| Approche | Exécution | Statut pertinent | BYOM | Conséquence de gouvernance |
|---|---|---|---|---|
| Agent prompt avec Copilot harness | Boucle et sandbox gérés par Foundry | Préversion publique | Non pris en charge | Socle géré, mais harness figé à la création |
| Hosted agent | Code de l’agent hébergé par Foundry | Résilience longue durée en disponibilité générale | Dépend de l’architecture retenue | Plus de liberté et davantage de contrôles à concevoir |
| Harness ou framework personnalisé | Exploitation définie par l’équipe | Dépend du déploiement | Dépend de l’implémentation | Contrôle maximal avec maintenance et évaluations à la charge de l’organisation |
Le BYOM, pour Bring Your Own Model, n’est pas pris en charge par le Copilot harness dans Foundry. Une organisation qui doit utiliser un modèle qu’elle apporte elle-même ne peut donc pas considérer cette préversion comme un remplacement direct de son architecture actuelle.
Il faut également distinguer les produits. Le passage en disponibilité générale d’un harness dans une autre surface ne modifie pas le statut du Copilot harness dans Foundry. Cette différence est notamment visible avec le harness GitHub Copilot dans Copilot Studio.
Pour les équipes Microsoft 365, le Copilot Managed Runtime répond à une autre problématique : l’exécution gérée de code dans l’environnement Copilot. Les deux approches réduisent la charge d’exploitation, sans couvrir les mêmes scénarios ni les mêmes frontières de données.
La Loi 25 déplace l’analyse du modèle vers toute la chaîne
Le multi-modèle ne réduit pas la gouvernance au choix d’un fournisseur ou d’un modèle. Pour un organisme soumis à la Loi 25, la décision doit couvrir l’agent complet : données reçues, modèle sélectionné, outils appelés, connexions externes, sorties produites et personnes autorisées à modifier sa configuration.
La FAQ de Foundry Agent Service précise que des données peuvent quitter Foundry lorsqu’un outil, une connexion ou un point de terminaison externe est configuré. Un changement de modèle ne corrige donc pas un flux de données mal maîtrisé au niveau des outils.
Illustration : une équipe québécoise crée un agent chargé de produire un rapport à partir de documents internes. L’agent interroge un référentiel approuvé, puis appelle un service externe pour enrichir le résultat. Même si le modèle reste inchangé, ce second appel modifie la chaîne de traitement et doit être intégré au dossier de décision.
Dossier de décision pour un agent soumis à la Loi 25
- Définir la finalité de l’agent et désigner son propriétaire opérationnel
- Établir les catégories de données autorisées et celles qui doivent être exclues
- Documenter le modèle, sa version et les critères utilisés pour le retenir
- Inventorier chaque outil, connexion et point de terminaison externe
- Définir les rôles autorisés à publier une nouvelle version de l’agent
- Prévoir les tests, les preuves de validation et la procédure de retour arrière
Cette liste constitue un cadre de gouvernance technique. La qualification juridique et les contrôles applicables restent à valider avec les responsables de la protection des renseignements personnels et les équipes juridiques de l’organisation.
Les conversations définissent la frontière de version
Un changement de version d’agent n’interrompt pas automatiquement un environnement déjà actif. La documentation de configuration des agents indique qu’une nouvelle conversation utilise immédiatement la version sélectionnée, tandis qu’un environnement en cours peut conserver l’ancienne jusqu’à son passage à l’état inactif.
Cette nuance affecte les tests de non-régression et la traçabilité. Pour obtenir une frontière de version nette, Microsoft recommande de démarrer une nouvelle conversation après le changement.
Publier la version dans un environnement de validation
Associez la version à son modèle, à ses instructions, à ses connexions et aux versions de skills utilisées.
Démarrer une nouvelle conversation de test
N’utilisez pas une conversation déjà active pour conclure que la nouvelle version est correctement chargée.
Vérifier la reprise et les actions en double
Pour une tâche longue, contrôlez que l’agent sauvegarde sa progression et ne recrée pas un rapport, un ticket ou une autre ressource déjà produite.
La résilience longue durée des hosted agents est en disponibilité générale depuis octobre 2026. Foundry peut relancer un travail interrompu avec son entrée d’origine, mais le code doit gérer les points de reprise et l’idempotence. Sans ces protections, la résilience peut répéter une action déjà exécutée.
Les skills améliorent la réutilisation, pas automatiquement le contrôle
Les skills Foundry sont en préversion. Ils prennent la forme de dossiers contenant un fichier SKILL.md, selon le format ouvert Agent Skills, et sont versionnés par une API dédiée.
Un agent prompt utilisant le Copilot harness peut référencer ces skills. La documentation Microsoft Learn sur les skills permet d’épingler une version afin de conserver un instantané immuable. Lorsqu’aucune version n’est indiquée, Foundry fige la version par défaut disponible au moment de la référence.
L’épinglage simplifie la reproductibilité d’un test et l’analyse d’un incident. Il ne remplace pas la revue du contenu de SKILL.md, des outils mobilisés ni des autorisations accordées à l’agent.
Un outil externe peut déplacer la frontière de données
Questions fréquentes
Le Copilot harness dans Microsoft Foundry est-il en disponibilité générale ?
Non. Il est en préversion publique depuis octobre 2026. La disponibilité générale de la résilience longue durée des hosted agents concerne une capacité distincte.
Peut-on ajouter le Copilot harness à un agent existant ?
Non. Les agents existants ne changent pas et le harness se choisit pendant la création d’un nouvel agent prompt. Il n’est ensuite pas possible de remplacer ce harness.
Peut-on apporter son propre modèle au Copilot harness ?
Non. Le BYOM n’est pas pris en charge dans cette préversion de Foundry. Le choix reste limité aux modèles proposés dans le cadre du service.
Une nouvelle version remplace-t-elle immédiatement celle d’une conversation active ?
Pas nécessairement. Une nouvelle conversation utilise la version sélectionnée, mais un environnement déjà actif peut continuer avec l’ancienne version jusqu’à devenir inactif. Une nouvelle conversation fournit une séparation plus fiable pour les tests.
Quels coûts s’ajoutent après le 1er décembre 2026 ?
Le calcul du sandbox est facturé 0,0994 USD par vCPU-heure et sa mémoire 0,0118 USD par GiB-heure. L’inférence du modèle et les outils payants s’ajoutent à ces montants.
Trois décisions à prendre avant le pilote
Le premier pilote doit valider la gouvernance autant que la qualité des réponses. Une démonstration fonctionnelle ne suffit pas si elle ignore les versions, les appels externes ou le coût réel après la période gratuite.
Avant de créer le premier agent
- Choisir entre agent prompt avec harness, hosted agent et architecture personnalisée
- Confirmer que l’absence de BYOM est compatible avec la politique de modèles
- Sélectionner un cas d’usage limité avec des données approuvées
- Définir un jeu d’évaluation commun aux modèles comparés
- Épingler les versions des skills et conserver les résultats de validation
- Mesurer séparément le coût du sandbox, de l’inférence et des outils
- Tester une nouvelle conversation après chaque changement de version
Si l’organisation exige un modèle apporté par ses soins ou un contrôle complet de la boucle d’agent, elle doit conserver une approche hébergée ou personnalisée. Si elle privilégie une exécution gérée et des modèles pris en charge par Foundry, le Copilot harness mérite un pilote encadré, sans être traité comme un service déjà stabilisé.
Pour aller plus loin
- Introducing the Microsoft Copilot harness in Foundry Agent Service — le statut, la tarification et les critères de choix officiels.
- Foundry Agent Service FAQ – Microsoft Copilot harness — les limites de la préversion, le BYOM et les flux externes.
- Use skills in Foundry — la création, le versionnement et la référence des skills.
- What’s new in Microsoft Foundry | September 2026 — un exemple de harness Copilot SDK dans un hosted agent.
