Le harnais Microsoft Copilot arrive via Foundry, déplaçant la décision entre création et achat

Microsoft a ouvert son harnais Microsoft Copilot via Foundry le 28 octobre, étendant aux développeurs une fondation d’exécution interne tout en conservant le contrôle de son fonctionnement. Un harnais est le logiciel qui entoure un modèle d’IA et organise les instructions, le contexte, les outils et l’exécution. Cette annonce modifie ce que les entreprises peuvent acheter plutôt que construire, sans les décharger de leur responsabilité quant au travail produit.

Le choix central consiste à maintenir cette mécanique d’exécution en interne ou à adopter l’approche gérée de Microsoft. Un agent, logiciel qui utilise des modèles et des outils pour accomplir une tâche, a besoin de plus qu’un accès à un modèle performant. Quelqu’un doit décider de la manière dont il poursuit son travail, gère les échecs et reste dans les limites définies par l’entreprise.

Anthropic propose déjà une approche gérée concurrente, offrant aux acheteurs un point de comparaison utile au-delà de la famille de produits Microsoft. L’argument distinctif de Microsoft met l’accent sur l’accès à différentes familles de modèles par le biais d’une infrastructure partagée. Pour les équipes de développement, cela soulève une question pratique : quelles responsabilités deviennent plus faciles à déléguer, et lesquelles exigent toujours un jugement spécifique à l’application ?

Le harnais Microsoft Copilot entre en préversion publique dans Foundry

Microsoft transforme une fondation de produit partagée en brique de construction gérée pour les applications clientes.

Selon l’annonce du harnais multi-modèles de Microsoft, l’équipe d’ingénierie de GitHub a développé le harnais avant que Microsoft ne l’adopte dans l’ensemble des expériences Copilot. L’entreprise cite Copilot Code, Copilot Studio, l’application GitHub Copilot, l’interface en ligne de commande et VS Code parmi ses utilisateurs.

Foundry Agent Service, la plateforme de Microsoft destinée à la création et à l’exploitation d’agents, propose désormais le harnais en préversion publique. Ce statut importe, car l’annonce associe une technologie interne établie à un service géré nouvellement disponible. L’expérience acquise dans les produits Microsoft ne démontre pas automatiquement la préparation à toutes les charges de travail des clients externes.

Microsoft décrit une répartition des responsabilités dans laquelle elle exploite la mécanique d’exécution tandis que les clients fournissent leurs instructions et connexions propres à l’application. Cet arrangement rend le lancement pertinent au-delà des assistants de programmation. Une entreprise qui développe un assistant de recherche ou un agent opérationnel peut envisager d’acheter une infrastructure auparavant considérée comme un travail d’ingénierie interne.

L’annonce décrit également un kit de développement logiciel téléchargeable, un paquet que les développeurs utilisent pour intégrer la technologie à leurs applications. Cette voie ne doit pas être confondue avec l’expérience Foundry gérée. Choisir un mode de distribution et choisir qui exploite un service sont des décisions liées, mais elles répondent à des questions différentes.

Pour un acheteur en entreprise, le changement immédiat est l’ajout d’une option de mise en œuvre. Une équipe qui évalue un agent n’a plus besoin de supposer que la prise en charge de différents modèles exige de maintenir son propre système d’exécution environnant. Microsoft propose de maintenir cette fondation partagée pour le compte du client.

Cette offre mérite une lecture précise. Acheter un harnais géré ne démontre pas qu’un flux de travail particulier produit des réponses correctes ou des actions appropriées. Cela modifie l’entité qui fournit une partie de la mécanique. L’acheteur a toujours besoin de preuves que l’application complète respecte ses propres exigences.

Prenons une application de recherche hypothétique qui compare des annonces de fournisseurs et prépare une note interne. Son résultat utile comprend un sourçage exact, des dates claires et un traitement explicite des informations contradictoires. Un système d’exécution fonctionnel soutient ce travail, mais il ne peut pas définir ces exigences éditoriales pour l’organisation.

Le lancement déplace donc le point de départ des discussions architecturales. Au lieu de demander uniquement quel modèle doit répondre à une requête, les équipes peuvent se demander quelles parties de l’exécution des agents méritent une ingénierie sur mesure. C’est une question plus importante que de savoir si un autre modèle apparaît dans un menu de sélection.

La pression s’exerce sur les équipes qui maintiennent leur propre mécanique d’exécution

L’offre de Microsoft soumet les projets d’infrastructure internes à un examen attentif, surtout lorsqu’ils reproduisent des capacités sans créer d’avantage métier.

La pression la plus forte s’exerce sur les équipes applicatives qui maintiennent déjà la mécanique environnante des agents. Leurs responsables disposent désormais d’une alternative externe à examiner. Poursuivre une mise en œuvre sur mesure devient une décision qui doit être justifiée, plutôt qu’une condition préalable automatique au déploiement d’un agent.

Cette justification peut néanmoins être convaincante. Une entreprise peut exiger un comportement d’exécution inhabituel, des intégrations spécialisées ou un contrôle direct de la progression du travail. La distinction pertinente est de savoir si ces exigences influencent matériellement l’application. La propriété sur mesure est plus judicieuse lorsque l’organisation peut identifier ce que ce contrôle permet d’accomplir.

Acheter une infrastructure introduit une obligation différente : comprendre les limites du fournisseur. Une équipe de développement ne peut pas évaluer un service géré uniquement à partir des capacités présentées dans une démonstration. Elle doit identifier où s’arrête la plateforme et où commencent ses propres logiciels, procédures et mécanismes de supervision.

L’annonce de Microsoft sur l’exécution d’agents gérée présente les compétences, les outils connectés, l’exécution de fichiers et de code, ainsi que la délégation limitée. Les compétences sont des procédures réutilisables empaquetées avec des instructions et des ressources de soutien. Les outils donnent aux agents accès à des informations ou à des actions externes. Ces capacités décrivent une fondation applicative plus large que la seule génération de texte.

La même annonce offre le point de vue d’un premier client. Chris Evans, directeur technologique de Confluence Technologies, déclare que l’entreprise disposait d’une solution opérationnelle en moins d’une semaine. Il s’agit d’une anecdote de mise en œuvre utile, même si elle n’établit ni un calendrier de déploiement typique ni un résultat opérationnel à long terme.

Pour les acheteurs, la distinction importante se situe entre atteindre un état initial fonctionnel et maintenir un service fiable. Un prototype interne peut tolérer des hypothèses qu’une application opérationnelle ne peut pas accepter. Une fondation gérée peut raccourcir une partie du travail d’ingénierie tout en laissant sans réponse les examens d’intégration, les critères d’acceptation et les décisions de responsabilité.

Une comparaison financière utile examinerait donc le flux de travail complet plutôt qu’une seule réponse de modèle. Les considérations pertinentes comprennent la maintenance d’ingénierie, l’analyse des échecs, la revue humaine et les changements apportés aux systèmes connectés. Aucun calcul universel ne découle du lancement, car ces responsabilités diffèrent selon les organisations.

La pression atteint également les fournisseurs d’infrastructure dont les produits entourent les modèles. La distribution de Microsoft donne aux clients une raison supplémentaire de s’interroger sur les composants distincts dont ils ont besoin. Cela ne démontre pas que les produits indépendants deviennent inutiles. Cela relève le niveau d’exigence pour expliquer le contrôle, la visibilité ou la spécialisation supplémentaires qu’ils apportent.

Pour les travailleurs du savoir, les enjeux prennent une forme différente. Ils constatent si un agent produit un livrable exploitable, préserve les bonnes preuves et signale l’incertitude de manière appropriée. Un changement architectural compte pour eux lorsqu’il réduit les travaux incomplets ou rend les erreurs plus faciles à identifier et à corriger.

C’est pourquoi la discussion entre création et achat concerne autant les responsables produit que les ingénieurs. L’organisation doit définir un résultat satisfaisant avant de décider quel arrangement d’infrastructure le fournit. Sinon, un déploiement techniquement réussi peut laisser le problème métier réel largement intact.

Le choix du modèle et le contrôle de l’exécution sont des décisions distinctes

L’accès à différents modèles ne donne pas aux clients un contrôle illimité sur la manière dont le service géré exécute leur travail.

La FAQ sur la disponibilité du harnais de Microsoft définit les limites de la préversion. La prise en charge de l’apport de son propre modèle n’est pas disponible. Les clients sélectionnent le harnais lors de la création d’un nouvel agent prompt et ne peuvent pas le modifier ensuite. La disponibilité peut également varier selon la région, le client, les outils, le réseau et les quotas.

Ces restrictions précisent la signification de la prise en charge multi-modèles. Un client peut évaluer les choix pris en charge dans les limites du service. Cela diffère de l’hypothèse selon laquelle tout modèle, toute connexion ou tout arrangement de déploiement fonctionnera simplement parce que la stratégie globale met l’accent sur le choix.

Cette distinction importe lors des achats. La présence d’un modèle ailleurs dans le portefeuille d’un fournisseur ne répond pas à la question de savoir s’il est pris en charge dans une expérience gérée particulière. Les acheteurs doivent évaluer la combinaison qu’ils prévoient d’utiliser, y compris le lieu de déploiement pertinent et les systèmes connectés.

Il existe également une distinction entre modifier un modèle et préserver le comportement d’une application. Même si une interface reste cohérente, un modèle différent peut produire des décisions ou des résultats différents. Les responsables d’applications devraient considérer un changement de modèle comme un élément à évaluer au regard des exigences métier, plutôt que comme une simple substitution administrative.

Prenons un assistant d’approvisionnement hypothétique qui examine une proposition de fournisseur. Une tâche consiste à extraire les dates de livraison. Une autre consiste à interpréter une clause d’annulation ambiguë. L’organisation peut préférer des caractéristiques de modèle différentes pour ces activités, mais elle a toujours besoin d’une définition cohérente des preuves acceptables et de l’escalade.

Une fondation d’exécution partagée peut faciliter l’organisation de cette comparaison. Elle ne démontre pas que les mêmes instructions fonctionnent aussi bien avec tous les modèles pris en charge. Le résultat utile est une possibilité contrôlée de comparer les résultats, avec des enregistrements clairs de ce qui a changé et pourquoi.

L’architecture d’agents gérés d’Anthropic fournit une comparaison concurrentielle pertinente. Son compte rendu d’ingénierie d’avril 2026 décrit la séparation du modèle et du harnais des environnements d’exécution et des enregistrements de session durables. L’objectif déclaré est de permettre aux mises en œuvre d’évoluer derrière des interfaces stables.

Cette comparaison montre pourquoi la concurrence dans le secteur dépasse la sélection de modèles. Les fournisseurs sont également en concurrence sur les responsabilités d’exécution qu’ils peuvent absorber tout en préservant une interface sur laquelle les clients peuvent s’appuyer. L’accent mis par Microsoft sur plusieurs familles de modèles répond à une dimension de cette décision d’achat plus large.

Aucune de ces descriptions architecturales ne désigne un gagnant universel. Une entreprise qui choisit entre des approches gérées doit comparer son flux de travail réel, les intégrations requises et ses contraintes opérationnelles. Un service qui convient bien à une application peut imposer des hypothèses inadaptées à une autre.

Le compromis plus profond concerne l’endroit où réside la flexibilité. Une équipe peut conserver des choix parmi les modèles pris en charge tout en acceptant la conception d’exécution du fournisseur. Elle peut aussi préserver davantage de contrôle sur l’exécution et assumer la responsabilité de sa maintenance. Il s’agit de formes distinctes de flexibilité, avec des conséquences d’ingénierie différentes.

Pour le harness Microsoft Copilot, l’interprétation pratique la plus solide est donc celle d’un choix encadré. Les clients disposent d’une voie gérée supplémentaire pour le développement d’agents. Ils doivent évaluer cette voie selon ses capacités documentées, plutôt que de considérer le positionnement global comme une promesse de compatibilité universelle.

Les gains d’évaluation de Microsoft nécessitent une interprétation prudente

Les résultats internes de Microsoft justifient une évaluation plus approfondie, mais ils n’établissent pas des gains équivalents pour chaque application Foundry.

Dans ses résultats d’évaluation des agents, Microsoft compare le harness Copilot au harness Standard dans Copilot Studio. L’entreprise fait état d’améliorations du taux de réussite de 10,8 points de pourcentage avec un modèle OpenAI et de 22,1 points de pourcentage avec un modèle Anthropic.

Microsoft indique également la poursuite des tentatives après des appels d’outils échoués dans 84 à 91 % des cas évalués, contre moins de 7 % avec le harness Standard. Ses notes associées distinguent explicitement la poursuite de l’utilisation des outils et les nouvelles tentatives réussies de la réalisation réussie de la tâche globale. Il s’agit de conclusions rapportées par l’entreprise, sans validation indépendante établie ici.

Cette réserve est essentielle pour interpréter l’annonce. La persistance décrit le comportement après un problème. L’accomplissement décrit si le résultat demandé a été atteint. Un système peut continuer à fonctionner tout en comprenant mal la tâche, en utilisant des éléments inadaptés ou en produisant un résultat inacceptable.

La différence devient concrète dans un hypothétique flux de travail de service client. Un agent peut réussir à renouveler l’accès à un dossier tout en recommandant une mauvaise résolution. Mesurer la récupération après l’échec de connexion aide à expliquer le comportement d’exécution. Cela ne permet pas de déterminer si le client a reçu une réponse exacte.

De même, un taux de réussite d’évaluation plus élevé dépend de ce que l’évaluation demande. Les acheteurs doivent comprendre les tâches pertinentes, les critères d’acceptation et les configurations avant de transposer un résultat dans leur propre environnement. Une amélioration en points de pourcentage n’est informative qu’au regard du test qu’elle mesure.

Cela ne diminue pas l’importance du système d’exécution environnant. La comparaison rapportée par Microsoft est cohérente avec l’argument selon lequel la capacité du modèle seule ne détermine pas les résultats d’un agent. Elle donne aux clients une raison de tester les choix d’exécution parallèlement aux choix de modèles, tout en explicitant clairement l’attribution et les limites.

Microsoft décrit également une application interne de support ayant dépassé un taux de résolution entièrement autonome de 35 % en août 2026. L’entreprise définit cette mesure comme la résolution de cas sans intervention humaine. Il s’agit d’un déploiement concret rapporté, mais sa pertinence comme comparaison dépend des cas et des conditions d’exploitation.

Pour une entreprise évaluant une application similaire, l’autonomie doit être considérée aux côtés de l’exactitude et des conséquences. Un cas résolu sans intervention peut constituer un élément utile lorsque la résolution est exacte et appropriée. La seule absence d’intervention ne peut établir que le résultat répondait aux exigences de l’organisation.

L’évaluation doit également tenir compte du travail transféré aux réviseurs. Si un agent produit davantage de contenu mais exige des corrections substantielles, le volume de production peut donner une image trompeuse de sa contribution pratique. La question métier porte sur le travail achevé et acceptable, ainsi que sur l’effort nécessaire pour l’obtenir.

La même logique s’applique aux défaillances qui restent invisibles jusqu’à plus tard. Une note de synthèse soignée comportant une affirmation non étayée peut paraître réussie au moment de sa livraison. Une évaluation qui vérifie les preuves et l’attribution révélerait un résultat différent. Les critères d’acceptation doivent refléter la manière dont le résultat sera réellement utilisé.

Pour l’instant, les chiffres de Microsoft constituent des éléments utiles concernant ses propres environnements testés. Ils justifient une investigation sans remplacer des tests propres à chaque client. Les acheteurs doivent éviter de transformer une comparaison fournie par un fournisseur en prévision pour des charges de travail qui ne faisaient pas partie de l’évaluation rapportée.

L’exécution gérée laisse la responsabilité métier au client

Déléguer l’infrastructure ne transfère pas la responsabilité de décider ce qu’un agent est autorisé à faire.

La frontière la plus nette concerne les actions à conséquences importantes. Un agent qui prépare une recommandation et un agent qui engage l’organisation sur cette recommandation exigent des contrôles différents. Un service d’exécution géré peut prendre en charge l’un ou l’autre modèle, mais l’organisation doit décider où commencent et où s’arrêtent les pouvoirs d’autorisation.

Fashable offre une perspective client dans les éléments de lancement de Microsoft. Son directeur général, Orlando Ribas Fernandes, décrit des opportunités liées aux flux de travail d’approvisionnement, tout en maintenant les décisions commercialement contraignantes sous contrôle humain. Il s’agit d’une limite opérationnelle envisagée, plutôt que d’une preuve que chaque capacité proposée a déjà produit un résultat mesuré.

Cet exemple montre pourquoi la responsabilité ne peut être déduite de l’automatisation. Un assistant d’approvisionnement peut comparer des spécifications, identifier des informations manquantes ou préparer des éléments de négociation. Autoriser un achat introduit une responsabilité différente. La distinction doit rester visible même lorsque ces activités apparaissent dans une seule conversation.

Le travail de longue durée introduit une autre limite : mémoriser ce qui s’est produit plutôt que savoir ce qui reste valide. Un agent peut conserver un résultat antérieur sans savoir que les circonstances ont changé. Les responsables d’applications doivent déterminer quand des informations antérieures doivent être revérifiées et quelles décisions dépendent d’éléments actuels.

Les recherches d’Anthropic sur les agents de longue durée décrivent des échecs impliquant un travail incomplet et des déclarations prématurées d’achèvement entre les sessions. L’approche proposée utilise des enregistrements explicites de progression et un travail incrémental. La leçon plus large est que la poursuite de l’exécution exige un suivi fiable des obligations non achevées.

Pour les entreprises, cette leçon suggère de traiter l’achèvement comme une condition métier. Une tâche est terminée lorsque ses critères d’acceptation sont remplis, y compris toute révision ou confirmation requise. Un message final assuré ne peut remplacer la preuve que ces conditions sont respectées.

La reprise d’un travail interrompu crée une préoccupation connexe. Imaginez un agent hypothétique qui prépare un rapport et le soumet à un autre système. Si la soumission réussit mais que la confirmation est perdue, répéter l’action peut créer des enregistrements en double. L’application doit pouvoir distinguer une action inachevée d’une action non confirmée.

Microsoft a annoncé séparément la disponibilité générale de la résilience pour les agents de longue durée hébergés, pour lesquels les clients apportent leur propre logique d’exécution. Sa documentation attribue au code de l’application la responsabilité de la progression enregistrée et de la prévention des doublons. Cette fonctionnalité distincte ne doit pas être considérée comme une garantie générale pour le nouvel aperçu du harness.

La qualité de l’information crée une responsabilité supplémentaire. Un agent connecté à des instructions obsolètes peut exécuter ses consignes de manière cohérente tout en produisant un travail inadapté. Les équipes envisageant une base de connaissances consultable doivent considérer l’organisation et la maintenance des sources comme faisant partie de l’application.

Cette relation rend la gestion des connaissances pertinente pour le lancement sans impliquer une intégration particulière. L’infrastructure détermine la manière dont le travail avance ; les éléments disponibles limitent ce que l’agent peut raisonnablement conclure. Améliorer l’un n’élimine pas les faiblesses de l’autre.

Les organisations doivent donc attribuer la responsabilité sur l’ensemble du flux de travail. Quelqu’un doit être responsable des sources, des autorisations, des critères d’acceptation et des corrections lorsque les résultats échouent. L’exécution gérée peut modifier la charge d’ingénierie, mais elle ne supprime pas ces décisions organisationnelles.

Le cas d’adoption le plus crédible identifie à la fois le travail pris en charge par le fournisseur et les obligations que conserve le client. Cette clarté facilite l’évaluation de la capacité du service à réduire globalement la complexité. Elle évite également qu’un prototype réussi ne devienne une application dont personne ne possède pleinement la responsabilité.

Trois signaux montreront si l’approche gérée tient ses promesses

Les prochains éléments utiles concerneront la maturité du service, les résultats comparatifs et les opérations des clients plutôt que des affirmations de lancement supplémentaires.

Le premier signal sera la manière dont Microsoft développera l’aperçu Foundry au cours des prochains mois. Les acheteurs devront surveiller une disponibilité plus claire, les configurations prises en charge, les options de migration et les recommandations pour la production. Une prise en charge documentée plus large renforcerait l’argument en faveur de l’adoption d’une fondation gérée commune dans davantage d’applications.

L’extension la plus significative répondrait à une exigence bloquant actuellement un déploiement réel. Une autre configuration prise en charge compte lorsqu’elle permet à une organisation d’opérer dans ses contraintes techniques et métier. Une liste de fonctionnalités plus longue, à elle seule, en dit moins sur la viabilité d’une application donnée.

Si les restrictions de l’aperçu restent importantes pour l’environnement prévu par un client, le cas d’une adoption immédiate s’affaiblit pour ce client. Il s’agit d’un jugement propre à la charge de travail. Une limitation peut être sans importance pour un prototype de recherche et décisive pour une application connectée à des systèmes opérationnels sensibles.

Le deuxième signal sera constitué d’éléments comparatifs qui séparent les changements de modèle des changements d’exécution. Les évaluations doivent indiquer clairement quel composant a changé et comment la réussite a été mesurée. Cela aiderait les acheteurs à déterminer si le bénéfice rapporté provient du harness, du modèle ou de leur interaction.

Des évaluations indépendantes renforceraient la confiance, notamment si elles divulguent les catégories d’échecs et les exigences de révision. Une comparaison axée sur le travail achevé renforcerait plus directement l’argument de Microsoft qu’une comparaison axée uniquement sur l’activité. Des résultats montrant une dépendance importante à la configuration limiteraient l’ampleur avec laquelle l’affirmation devrait être appliquée.

Les évolutions concurrentielles comptent dans cette même comparaison. Les changements apportés à l’offre gérée d’Anthropic, ou à l’approche d’exécution d’un autre fournisseur, peuvent modifier les alternatives disponibles. Les acheteurs doivent comparer les services à une exigence applicative stable afin qu’un marché en évolution ne transforme pas l’évaluation en une course sans fin aux fonctionnalités.

Le troisième signal sera le retour des clients au-delà de la vitesse de déploiement initiale. Les témoignages utiles décriraient une exploitation durable, des résultats acceptables, l’effort de correction et les responsabilités conservées par le client. Des preuves d’une maintenance réduite associée à des résultats fiables renforceraient l’argument en faveur de l’achat de la couche d’exécution partagée.

Les témoignages faisant état d’un travail sur mesure important nécessiteraient une lecture plus attentive. La personnalisation peut refléter une spécialisation métier précieuse ou des lacunes du service géré. Comprendre quelle explication s’applique compte davantage que de simplement comptabiliser la quantité de code écrite par un client.

Ces signaux fournissent également un moyen pratique de réexaminer une décision antérieure. Une équipe peut raisonnablement construire son propre système d’exécution aujourd’hui et adopter plus tard un service géré. Une autre peut commencer avec une infrastructure gérée et ne la conserver que tant que cet arrangement continue de répondre à ses exigences.

Évaluez le harnais Microsoft Copilot au regard d’un flux de travail que votre organisation maîtrise bien. Définissez un résultat acceptable, identifiez les actions nécessitant une approbation et consignez les cas où une correction humaine reste nécessaire. Comparez l’option gérée à votre approche existante en vous appuyant sur les mêmes éléments de preuve et critères d’achèvement. Tenez compte de la qualité des sources, du comportement de récupération et de l’effort requis pour examiner les erreurs. Gardez la décision liée aux responsabilités que votre équipe peut réellement déléguer, puis réévaluez-la à mesure que le support documenté et les retours des clients se développent. Le lancement de Microsoft offre une alternative concrète au maintien en interne de l’ensemble de la fondation d’exécution. L’étape utile suivante consiste à déterminer quelles parties de votre propre flux de travail cette alternative améliore, et quels éléments de preuve pourraient faire évoluer votre décision