Fabrice Frossard

TL;DR

• Copilot Studio quitte le low-code pour l’ingénierie agentique. Trois “harnesses” (GitHub Copilot, Standard, Copilot Chat) formalisent des niveaux de contrôle différents : exécution autonome de bout en bout, workflows déterministes, ou enrichissement de M365 Copilot. Les Skills (SKILL.md) deviennent des blocs de comportement réutilisables entre agents, mais c’est l’orchestrateur qui décide seul de les invoquer, avec les problèmes de fiabilité et de debugging que ça soulève déjà sur r/copilotstudio. Microsoft muscle en parallèle la gouvernance des modèles (cycle de vie, tests, migrations) et des coûts (Copilot Credits, estimateur non garanti).
• Côté entreprise, trois échéances concrètes à anticiper : fin de la création d’agents “classic” via Teams (30 juin 2026), bascule de facturation messages : Copilot Credits (déjà effective depuis septembre 2025), suppression des crédits AI Builder inclus dans certaines licences (novembre 2026).
• La question n’est plus ce qu’un agent sait faire, mais ce qu’on accepte de le laisser décider seul.

Qui décide, dans une entreprise, quand une IA doit suivre une procédure et quand elle peut improviser ? En août 2026, Microsoft répond furtivement à cette question en silence, dans un guide de licence et une doc technique, et cette réponse change la nature de Copilot Studio. De même que l’interface de création d’agents, scindée en deux partie, agents et workflows.

Petit rappel des faits. Pendant deux ans, Copilot Studio revendiquait le statut d’outil low-code. Les équipes IT y assemblaient des topics et branchaient des connecteurs pour obtenir un assistant conversationnel relié aux données de l’entreprise. Ce mois-ci, Microsoft formalise trois architectures d’exécution distinctes, les « harnesses », développe les Skills comme composants réutilisables, les structure autour d’un fichier SKILL.md, et muscle en parallèle sa gouvernance des modèles et de la consommation. Rien de spectaculaire pris isolément. Mis bout à bout, ces trois couches déplacent Copilot Studio du low-code vers l’ingénierie agentique.

Trois harnesses, trois philosophies du contrôle

Le terme « harness » prête à confusion parce qu’il ne désigne ni le modèle ni l’agent, mais l’environnement qui organise leur relation : le contexte transmis, les outils accessibles, la façon dont une tâche s’exécute. Le modèle apporte l’intelligence brute. Le harness décide comment cette intelligence s’emploie.

Le GitHub Copilot Harness vise l’exécution agentique de bout en bout. Microsoft l’illustre avec un agent de comptabilité fournisseurs qui lit des factures, les rapproche des bons de commande et route les exceptions vers un humain. L’objectif n’est plus de répondre à une question mais de tenir un processus métier complet, avec un runtime capable de sélectionner dynamiquement les outils et les connaissances nécessaires.

Le Standard Harness reste fidèle à l’ADN historique de la plateforme : topics, règles, chemins définis à l’avance. Un agent d’onboarding informatique qui fait passer une demande de PC par ses étapes d’approbation en est l’exemple canonique. Et c’est là le point que beaucoup d’observateurs de l’IA agentique oublient de dire. Agentique ne signifie pas qu’il faut tout abandonner à la décision du modèle. Un processus qui doit rester déterministe le reste, quelle que soit la sophistication de l’orchestrateur.

Le Copilot Chat Harness, enfin, personnalise Microsoft 365 Copilot avec les données propres à l’organisation, via SharePoint notamment. Trois harnesses, donc trois façons d’assumer un même arbitrage. Combien de liberté l’entreprise laisse-t-elle à la machine ? Le choix du harness n’est plus un paramètre technique secondaire. C’est une décision d’architecture, au même titre que le choix d’une base de données ou d’un cloud.

SKILL.md, quand le comportement devient du code

Deuxième mouvement, plus discret mais tout aussi structurant. Les Skills en sont le vecteur, et elles ne sortent pas de nulle part. Microsoft les mentionnait déjà en juin 2026, à l’occasion de la nouvelle expérience Copilot Studio. Ce qui change en août, c’est leur documentation et leur rôle dans l’architecture, désormais beaucoup plus explicites. Un outil permet à l’agent d’agir sur un système externe, une API, un connecteur. Une Skill lui indique comment accomplir un type de tâche. Microsoft la définit comme un ensemble autonome et réutilisable d’instructions, packagé dans un fichier Markdown dont le front matter YAML porte le nom et la description de la compétence, exportable et partageable entre agents.

Prenez une banque. Une Skill « ouverture de compte » décrit la collecte des informations client, la vérification des informations obligatoires, l’identification des justificatifs nécessaires, l’appel aux outils de contrôle appropriés, puis la transmission du dossier au système métier. Cette même Skill sert ensuite à plusieurs agents, sans réécriture.

On peut appeler cela du Behavior-as-Code. Le terme n’existe dans aucune fiche produit de Microsoft, mais il décrit exactement ce qui se joue. Plutôt que d’enfermer le comportement d’un agent dans une instruction fleuve ou dans des dizaines de branches conversationnelles cousues à la main, certaines règles métier deviennent des composants déclaratifs, lisibles, versionnables. Une Skill « qualifier un prospect » ou « analyser un contrat » devient un actif de l’organisation, détaché de l’agent qui l’exécute un jour donné.

Reste une question que la documentation ne tranche pas : qui décide du moment où cette Skill s’active ?

Sur r/copilotstudio, la fiabilité rattrape la promesse

C’est précisément ce qui remonte des retours d’utilisateurs avancés sur le subreddit r/copilotstudio. Témoignages individuels, pas une mesure représentative, mais un signal cohérent. Un échange récent sur l’articulation entre Skills, sous-agents et prompt engineering illustre le paradoxe. Son auteur salue la modularité et la traçabilité des Skills, avant de constater qu’elles ne sont pas systématiquement invoquées quand l’orchestrateur juge qu’elles ne sont pas nécessaires.

Cette mécanique dessine une règle d’architecture simple à énoncer, plus difficile à appliquer. Une étape qui peut être laissée à l’appréciation du système relève de la Skill et de l’orchestration générative. Une étape qui doit impérativement avoir lieu relève d’un workflow déterministe. L’avenir de Copilot Studio n’oppose donc pas les deux logiques. Il exige de savoir laquelle affecter à quoi, tâche par tâche.

D’autres fils communautaires documentent la friction propre à toute nouvelle architecture. Un utilisateur ayant migré vers la nouvelle expérience pour exploiter les Skills rapporte un délai entre la modification des instructions d’un agent et sa prise en compte réelle en environnement de test. D’autres signalent des difficultés avec certains connecteurs, avec Dataverse MCP, ou avec des workflows utilisant des connexions fournies par l’utilisateur à l’exécution, une fonctionnalité que l’un des auteurs précise lui-même tester en preview. Rien qui démontre une instabilité intrinsèque.

Ces frictions montrent surtout que déboguer un système agentique se complique mécaniquement à mesure que l’orchestrateur gagne en liberté. La question n’est plus « mon workflow fonctionne-t-il ? ». Elle devient « pourquoi l’orchestrateur a-t-il choisi cette Skill, ce connecteur, cette source, à cet instant précis ? ». Le changement de nature est considérable, même s’il ne fait aucun bruit.

Après le prompt engineering, l’agent engineering

Microsoft semble avoir anticipé ce basculement. Sa documentation d’août insiste sur l’évaluation, les tests, les architectures de référence, et ajoute des ressources dédiées à la gestion du cycle de vie des modèles. Changer de modèle sous un agent n’est plus une opération technique anodine. Microsoft recommande d’identifier les agents concernés, d’établir des évaluations de référence, de tester les modèles candidats, d’analyser les régressions, puis de surveiller la migration. Un agent devient un système vivant, dont le comportement bouge dès que son modèle, ses instructions, ses outils ou ses connaissances bougent.

Des coûts, difficile à évaluer, dès la phase de test

La même professionnalisation touche les coûts. Les agents consomment désormais des Copilot Credits, et ceux qui tournent sous GitHub Copilot Harness en consomment à la fois pendant leur construction et leur exécution. Microsoft propose un estimateur de consommation mensuelle, ventilé par connaissances, actions, flows et autres activités, en précisant lui-même qu’il s’agit d’une estimation, pas d’une garantie du coût réel. Sur les forums, certains utilisateurs cherchent déjà comment éviter la facture surprise d’un agent devenu trop autonome. Après le Cloud FinOps, voici venir l’Agent FinOps. Il ne s’agit plus seulement de mesurer ce que coûte un agent, mais quelles opérations, quels modèles, quelles architectures justifient cette dépense.

Ce que les entreprises doivent trancher, et vite

Ces mutations ne restent pas théoriques. Elles imposent un calendrier de décisions. Microsoft l’a documenté dans son centre de messages. Côté création, la fabrication d’agents « classic » depuis l’application Teams de Copilot Studio s’est arrêtée le 30 juin 2026. Les agents déjà en production continuent de fonctionner, mais toute nouvelle création bascule vers l’application web, ce qui suppose de former les équipes concernées et de mettre à jour la documentation interne avant l’échéance.

Côté facturation, le repère a déjà bougé une première fois : depuis le 1er septembre 2025, la consommation des agents ne se compte plus en messages mais en Copilot Credits, devenus la monnaie commune de toutes les capacités de la plateforme. Une seconde bascule suivra en novembre 2026, quand les crédits AI Builder intégrés à certaines licences Power Platform et Dynamics 365 disparaissent au profit des seuls Copilot Credits. Pour une direction des systèmes d’information, ces dates ne sont pas de simples lignes dans une note de version. Elles appellent un audit des agents classic encore en production, une refonte du budget de consommation calé sur les crédits plutôt que sur les messages, et un arbitrage assumé sur le harness retenu, sachant que le GitHub Copilot Harness facture la construction autant que l’exécution, contrairement aux logiques plus sobres du Standard Harness.

Le vrai sujet n’est plus ce que l’agent sait faire

Trois couches résument les modifications d’août 2026. Le harness définit comment l’agent fonctionne. Les Skills définissent des capacités métier réutilisables. La gouvernance encadre les modèles, la performance et la consommation. Une pile complète, cohérente avec la stratégie plus large de Microsoft autour de sa « Frontier Transformation », celle qui doit faire passer les organisations de l’expérimentation IA à son intégration réelle dans les processus.

Mais la communauté d’utilisateurs apporte le contrepoint que la documentation officielle ne fournit jamais. Plus un agent gagne en autonomie, plus les questions de déterminisme, d’observabilité, de debugging, d’identité, de tests et de coût prennent le pas sur celle de la capacité brute. Microsoft automatise la construction et le raisonnement des agents. Cette simplicité apparente oblige en retour les entreprises à une rigueur d’architecture qu’elles n’avaient encore jamais eu à formaliser pour un simple chatbot.

Copilot Studio a cessé d’être un outil pour fabriquer des copilotes. Il devient une plateforme pour construire des systèmes agentiques d’entreprise. Et la question qui compte n’est plus ce qu’un agent sait faire. C’est ce que l’entreprise accepte de le laisser décider seul.

Quelques liens sur ces annonces :

Harnesses

• Vue d’ensemble et choix du harness : https://learn.microsoft.com/en-us/microsoft-copilot-studio/harnesses-overview
• Licence du Standard Harness : https://learn.microsoft.com/en-us/microsoft-copilot-studio/requirements-licensing-subscriptions

Skills et SKILL.md

• Vue d’ensemble des Skills (harness GitHub Copilot) : https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/skills-overview

Facturation et gouvernance des coûts

• Licensing et Copilot Credits (harness standard) : https://learn.microsoft.com/en-us/microsoft-copilot-studio/billing-licensing
• Nouveautés générales de Copilot Studio (fil des mises à jour, y compris GA du harness GitHub Copilot le 3 août 2026) : https://learn.microsoft.com/en-us/microsoft-copilot-studio/whats-new
• AI Builder credits vs Copilot Credits (retrait des crédits inclus, novembre 2026) : https://learn.microsoft.com/ai-builder/ai-builder-trials

Retraits / fin de l’ancienne expérience

• Message Center MC1315217, création d’agents “classic” via Teams, retrait le 30 juin 2026 : https://mc.merill.net/message/MC1315217 (miroir non officiel de l’annonce publiée dans le Microsoft 365 Message Center, accessible uniquement aux admins connectés dans le tenant d’origine)