Le harness est le système autour du modèle
Le 28 octobre, Microsoft a annoncé le Copilot harness dans Foundry Agent Service en préversion publique. Dans ce contexte, le modèle interprète des instructions et produit des réponses ; le harness coordonne le reste : contexte, outils, exécution, état et boucle qui détermine la suite. Microsoft indique qu’une stratégie de harness commune soutient plusieurs expériences Copilot et que les développeurs peuvent maintenant utiliser une version gérée dans Foundry.
Cette distinction compte : changer de modèle ne fournit pas automatiquement des permissions fiables, une reprise après erreur ou la logique du flux. Un agent qui recherche des sources et prépare une note a besoin d’éléments approuvés, d’un environnement contrôlé et d’un moyen de vérifier le résultat. Le harness est la couche opérationnelle qui relie ces éléments ; ce n’est ni un nouveau modèle de fondation ni une garantie de réussite.
Ce que comprend la préversion Foundry
Microsoft présente des skills réutilisables, des outils Foundry et MCP connectés, l’exécution sur des fichiers et du code, des sous-agents intégrés aux tâches bornées et des définitions d’agents gérées avec le code source. Le service géré exécute la boucle et le sandbox ; le développeur apporte connaissances, procédures et outils. Il peut choisir un modèle Foundry pris en charge sans reconstruire l’orchestration à chaque changement.
L’entreprise indique que l’authentification et les approbations des outils sont configurées explicitement et que des limites et politiques encadrent les tâches. Microsoft a annoncé séparément la disponibilité générale de la résilience de longue durée pour les agents hébergés ; ce statut ne concerne pas le harness Copilot lui-même, qui reste en préversion. Il faut vérifier accès, régions, coûts et modèles pris en charge dans la documentation du tenant.
Pourquoi utiliser plusieurs modèles — et quelles contraintes
Une équipe peut choisir un modèle plus rapide et moins coûteux pour extraire des données structurées, puis un modèle de raisonnement plus fort pour un cas difficile. Séparer l’orchestration du modèle peut faciliter ce choix. Cela peut aussi réduire certains liens à un fournisseur si les définitions, outils et tests sont portables. Microsoft décrit un choix parmi les modèles pris en charge dans Foundry, pas une substitution sans restriction pour tous les flux.
Le routage soulève de nouvelles questions : quelle preuve détermine le modèle, comment mesurer les coûts et que faire si deux modèles donnent des résultats incompatibles ? Testez chaque configuration sur le même jeu de tâches, surveillez les erreurs d’outils et gardez une approbation humaine pour les actions importantes. La version du harness, le contexte et la politique de sécurité influencent aussi le résultat.
Évaluer la gouvernance avant un projet pilote
Commencez par un flux étroit à faible impact et donnez à l’agent uniquement les données et outils nécessaires. Vérifiez les autorisations d’authentification, approbations, fichiers, journaux, durée, limites des sous-agents et procédures d’arrêt ou de reprise. Pour MCP, examinez chaque serveur et outil comme une intégration avec ses propres permissions et risques : le protocole ne fournit pas à lui seul la gouvernance.
La préversion peut éviter de construire une partie de l’infrastructure, mais elle crée une dépendance de plateforme à évaluer avec les gains de simplicité. Documentez les définitions et skills exportables, l’effet des modèles, les coûts après toute période de préversion et le chemin de migration. Copilot, Foundry Agent Service et le harness sont liés, mais restent des surfaces distinctes.
Un pilote utile doit définir le contrat entre le modèle et chaque système métier : quelles preuves sont requises avant l’exécution d’un outil, quelles actions nécessitent une validation, quelles données figurent dans les journaux d’audit et qui prend en charge une exécution partielle ou en échec. Consignez le modèle choisi ainsi que les versions du harness et des skills avec les résultats des tests. Le routage selon le coût et les performances devient alors mesurable, et l’on distingue une limite du modèle d’un problème d’outil, de permission ou d’orchestration. La portabilité se vérifie dans les configurations, pas dans une étiquette multi-modèle.
Sources et références
Une erreur factuelle à signaler ou une source à suggérer ? Contacter la rédaction.
