Le canvas d'automatisation déménage : Copilot Studio Workflows vs Power Automate

Microsoft déplace le canvas d'automatisation

Pendant dix ans, construire de l'automatisation sur la Power Platform voulait dire un seul endroit : Power Automate. Cela change. Copilot Studio embarque désormais sa propre surface d'automatisation, la nouvelle expérience Workflows, un designer visuel repensé avec du test au niveau du noeud et des actions AI natives. Le pitch est limpide : construisez vos automatisations là où vivent déjà vos agents.

La vraie question n'est pas de savoir si le nouveau designer est plus joli. Elle est de savoir ce qui se passe en dessous, et ce qu'un pro-dev ou un pipeline ALM peut réellement en faire aujourd'hui. La façon honnête d'y répondre est de construire la même chose deux fois et de mesurer les deux côtés.

Le scénario : un seul flow d'approbation par email. Une demande arrive, un approbateur est sollicité pour approuver ou rejeter, et le demandeur reçoit un email dans les deux cas. Quatre étapes logiques. Construit une fois en Power Automate classique, une fois dans le nouveau designer Copilot Studio Workflows, sur le même tenant de développement.

Le côté Power Automate : scriptable de bout en bout

Le build Power Automate sert de référence car c'est un chemin entièrement résolu. Le flow est un trigger manuel avec quatre inputs (Requester, Approver, RequestTitle, RequestDetails), une action Start and wait for an approval, une Condition sur l'outcome de l'approbation, et deux branches Send an email pour les cas approuvé et rejeté.

Voici ce que ce build a mesuré :

Le flow entier a été écrit à la main en JSON, packagé dans une solution, puis importé via pac solution import. Aucun clic dans un designer. Après l'import, une requête sur la Dataverse Web API a confirmé que le flow arrive comme une unique ligne workflow en category=5 (Modern Flow), en état draft, exactement comme attendu avant le binding de ses connection references.

Ce qu'il faut retenir : l'automatisation Power Automate est scriptable de la définition au déploiement. JSON vers solution package vers import, prouvé en direct en une trentaine de secondes. C'est la barre que la nouvelle expérience doit franchir.

Le côté Copilot Studio : le même artefact, un autre mur

Voici le constat qui rend cette comparaison digne d'être écrite. Quand on regarde où un Copilot Studio Workflow est réellement stocké, ce n'est pas un objet d'un nouveau genre. L'ancien format agent-flow comme le nouveau format Workflows persistent dans la même table Dataverse workflow standard, en category=5, type=1, avec le corps du flow dans la colonne clientdata. Le flow Power Automate de référence arrive dans cette même table, dans cette même catégorie.

Autrement dit, l'artefact stocké est identique dans sa forme. Un Workflow est une ligne workflow Dataverse ordinaire, attachée à un agent via la relation many-to-many botcomponent_workflow. Il n'existe pas de type de composant séparé qui représenterait le corps du flow ; le corps vit dans la table workflow et est référencé par l'agent. Cela signifie qu'un Copilot Studio Workflow est, en principe, transportable par le même mécanisme de solution package que celui utilisé côté Power Automate.

Donc si le stockage est identique et que c'est transportable par solution, où est l'écart ?

L'écart est l'authoring. Le nouveau designer Workflows est UI-only en public preview.

• La création est exclusivement un click-path : Workflows, puis New workflow, puis ajouter un trigger et construire dans le designer. Aucun chemin de création par API ou CLI n'est documenté, et aucun n'existe dans pac.
• La surface de commande pac copilot opère sur un agent entier uniquement. Elle peut lister, extraire un template, cloner un bot entier depuis un template, et publier. Aucun verbe n'authore un Workflow individuel. pac solution import/export/clone déplace le conteneur ; il ne construit pas le flow à l'intérieur.
• L'édition passe par l'ouverture du workflow dans l'onglet Build du designer. Il n'y a pas de chemin d'édition headless.
• La documentation de Microsoft répète, sur chaque page de la nouvelle expérience, que les agents et workflows créés dans la nouvelle expérience ne peuvent pas être convertis vers l'expérience classique. Il n'y a pas de downgrade ni de fallback d'interopérabilité.
• L'ALM en dehors du designer se limite à l'export et l'import de solution, et même là, les composants requis doivent être ajoutés dans l'UI. L'authoring ne quitte jamais le canvas Copilot Studio.

Ce que cela implique pour l'ALM et le pro-dev aujourd'hui

Si votre pratique d'automatisation dépend de définitions de flow versionnées, de revue de code du JSON et de déploiement scripté, la nouvelle expérience ne rentre pas encore dans ce moule. Vous pouvez déplacer un Workflow fini entre environnements dans une solution, mais vous ne pouvez ni générer ni diff son corps en dehors du designer. Chaque changement significatif de l'automatisation passe par un humain dans le canvas Copilot Studio.

C'est une contrainte réelle pour les équipes qui ont investi dans des pipelines. La transportabilité est bien réelle et utile, donc un Workflow approuvé peut voyager à travers vos environnements. Mais la boucle de création et d'édition est manuelle, et il n'y a pas de pont de retour vers le designer classique si vous décidez que la nouvelle expérience ne convient pas à un flow donné.

Pour un maker qui construit à l'intérieur d'un agent, tout cela importe peu : le designer est de toute façon là où vous voulez être, et les actions AI natives, un noeud Define Variables qui regroupe plusieurs opérations, et le test au niveau du noeud sont de vraies améliorations par rapport à l'assemblage de connectors. La tension est spécifiquement entre le nouveau canvas et le monde automatisé et scripté que Power Automate classique a passé des années à rendre possible.

Le billing fonctionne aussi différemment

Il y a une seconde différence qui apparaîtra sur la facture, pas dans le designer. Les Copilot Studio Workflows consomment de la capacité Copilot Studio pour chaque action qu'ils exécutent. Chaque action qu'un Workflow exécute est facturée sur la capacité Copilot Studio prépayée, et une fois cette capacité épuisée, les nouveaux runs sont bloqués.

Deux exemptions comptent. Les test runs depuis l'intérieur du designer ne consomment pas de capacité, donc itérer sur un build est gratuit. Et les utilisateurs licenciés pour Microsoft 365 Copilot sont exemptés pour leurs propres runs. Mais le modèle est fondamentalement différent du licensing per-flow ou seeded de Power Automate. Si vous avez l'habitude de raisonner le coût d'automatisation en termes de flows et de sièges, la nouvelle expérience vous demande de raisonner en termes d'actions exécutées contre un pool de capacité qui peut se vider et arrêter vos automatisations.

Verdict : une preview, pas un verdict

La lecture honnête est que ceci est une preview, et les previews sont des instantanés, pas des destinations. La nouvelle expérience Workflows n'est explicitement pas pour la production, et sa fonctionnalité est restreinte pendant qu'elle mûrit.

Ce que la comparaison établit aujourd'hui est précis et mesurable. L'artefact stocké est le même workflow Dataverse category-5 des deux côtés, et il est transportable par solution dans les deux cas. Power Automate reste entièrement scriptable, d'une définition JSON à un solution package jusqu'à un import terminé en une trentaine de secondes. Le nouveau designer Copilot Studio est UI-only pour l'authoring, sans API, sans CLI, et sans chemin de retour vers le designer classique, et il facture par action contre la capacité Copilot Studio.

Rien de tout cela n'est une critique de la direction. Rapatrier l'automatisation dans Copilot Studio, à côté des agents qu'elle sert, est un mouvement cohérent, et le designer lui-même est un pas en avant pour les makers. L'écart à surveiller est la surface de scripting. Quand la nouvelle expérience gagnera une API d'authoring et une vraie histoire ALM, le monde pro-dev rattrapera le canvas. D'ici là, la bonne posture est de savoir exactement de quel côté de la ligne se trouve chacun de vos flows, et de re-vérifier toute la comparaison à la general availability, car tout ce qui précède est mesuré contre une public preview et une preview n'est pas définitive.