Copilot Studio a été refait pendant que vos agents tournaient

En bref. Microsoft a reconstruit Copilot Studio. Le comportement d’un agent s’écrit maintenant en fichiers Markdown chargés à la demande, un nouvel orchestrateur fait le gros du travail, et l’expérience classique continue de tourner en parallèle. La vraie question n’est pas de migrer, c’est de choisir quoi garder.

Ce qui a changé

Le 9 juin 2026, Microsoft a publié la reconstruction de Copilot Studio. Les neuf onglets de configuration passent à quatre : construire, prévisualiser, évaluer, surveiller. Le reste est ailleurs, dans le même écran.

Sous le capot, l’orchestrateur est neuf. Il est bâti sur un harnais de codage et une couche de ligne de commande, ce qui lui donne une meilleure tenue des instructions, la capacité de travailler sur des tâches longues et de décomposer un problème en sous-tâches, de traiter de gros volumes de contenu et de produire des fichiers. En clair, il se comporte plus comme un agent de codage que comme un moteur de dialogue.

La nouveauté la plus visible, ce sont les skills. Une skill est un fichier Markdown avec un nom, une description et un corps d’instructions. L’orchestrateur lit les descriptions, puis charge le contenu complet seulement quand la tâche le demande. On peut les écrire à la main, les téléverser, les réutiliser d’un agent à l’autre, et importer celles qu’on a déjà pour GitHub Copilot ou Claude Code.

Autour de ça : des skills, des outils, de la connaissance et des agents connectés comme surfaces principales, une surface de mémoire en aperçu, et un nouveau concepteur de workflows avec des nœuds d’agent et des serveurs MCP en aperçu. L’expérience classique n’a pas disparu, elle coexiste.

Pourquoi ce n’est pas un relookage

Le vrai déplacement est là : le comportement sort du bloc d’instructions.

Avant, tout tenait dans un bloc qui plafonne, et les règles s’y empilaient jusqu’à ce que plus personne ne sache laquelle s’applique. Maintenant, chaque procédure est un fichier nommé, chargé seulement quand il sert. Le reste du temps, il ne coûte rien au contexte.

Ce qui change pour vrai, c’est que le comportement devient un actif versionnable. Un fichier Markdown se met dans un dépôt, se révise en pull request, se partage entre agents et garde un historique. C’est la bascule que j’ai déjà vue dans le développement logiciel : la logique sort de la configuration pour entrer dans le code.

Le format est ouvert, et c’est délibéré. Le même fichier sert chez Microsoft, chez GitHub Copilot et chez Claude. Un comportement écrit une fois peut suivre une organisation d’un outil à l’autre, ce qui n’était pas le cas des sujets et des gabarits d’il y a deux ans.

Ce qu’il ne faut pas migrer

L’expérience classique reste supportée. Elle tourne, elle est éprouvée, et rien n’oblige à y toucher. Les agents que je garde dans le classique sont ceux qui répondent à trois critères.

Des sujets stables dont le routage est testé depuis des mois, avec des exceptions que quelqu’un a réglées à la main et que personne ne veut redécouvrir. Des dialogues transactionnels courts, avec des cartes et des boutons, où la valeur vient de la précision du chemin. Et tout ce qui touche un processus réglementé où chaque chemin est scripté exprès, parce qu’une déviation y est un défaut.

Deux pièges à connaître avant d’ouvrir la nouvelle expérience. Les sujets ne sont pas des skills : remplacer un routage par un fichier de procédure ne reproduit pas le même comportement, et la documentation le dit à sa manière en déconseillant l’exercice pour les scénarios complexes. Ensuite, un agent construit dans la nouvelle expérience ne revient pas dans la classique. La décision se prend à la construction, pas après.

Ce que ça change dans une fabrique d’agents

Dans une fabrique d’agents, il y a trois objets : un cadre de garde-fous, des jeux de tests comme porte de sortie, un registre avec un propriétaire par agent.

La refonte déplace le premier. Mes garde-fous existaient en deux copies, un bloc dans le prompt et un fichier de connaissance. La deuxième copie devient une skill versionnée. Même contenu, mais désormais un seul endroit, un propriétaire et un historique de révision. Concrètement, une règle de ton ou une règle d’escalade devient une pull request au lieu d’une modification invisible dans une interface que personne ne relit.

Les jeux de tests ne bougent pas, et c’est la partie rassurante. La porte de sortie reste la même, avec un seuil fixé par usage et des cas ratés corrigés avant la mise en production. Pendant une reconstruction de plateforme, c’est ce qui permet de dormir.

Le registre devient plus important, pas moins. Plus construire un agent est facile, plus il y a d’agents. L’inventaire, l’identité par agent et la revue cyclique restent le seul endroit où on décide ce qu’on garde et ce qu’on éteint. Une équipe qui n’a jamais retiré un agent n’a pas de gouvernance, elle a une collection.

Pour finir

La règle que j’applique vient de la documentation elle-même, et je la trouve juste : chaque comportement appartient au plus petit composant qui le rend fiable et inspectable. Les instructions portent ce qui est toujours vrai, la connaissance porte les faits, les outils portent les actions, les skills portent les procédures, et les agents connectés portent les domaines qui appartiennent à une autre équipe.

Pour choisir entre les deux expériences, la question utile n’est pas laquelle est la plus récente. C’est : ce que je construis là, est-ce que ça a besoin de raisonner sur plusieurs étapes, de traiter des documents et de produire des fichiers, ou est-ce que ça a besoin d’un chemin prévisible et auditable jusqu’au bouton près? La réponse est dans l’usage, pas dans l’annonce.

Et la question à poser à un partenaire : est-ce qu’il vous parle de la migration en termes de fichiers, de dépôt et de tests, ou en termes de boutons à cliquer dans une nouvelle interface? La première réponse veut dire qu’il a lu la documentation.

Si vous avez des agents qui tournent et une exploration du nouveau à faire sans casser ce qui marche, c’est un atelier de deux heures avec votre équipe : on classe votre parc, on décide ce qui reste, ce qui se construit dans le nouveau et ce qui se retire. Écrivez-moi.

Bonne semaine!

Sources : Microsoft, « Meet the new Copilot Studio », 9 juin 2026, Microsoft Learn, Copilot Studio, Microsoft Build 2026.