Migrer les macros Excel VBA vers Power Automate — Ce qu'il faut remplacer par des scripts Office, et ce qu'il faut garder en VBA

« Ce traitement tourne sur une macro Excel, mais la personne qui l’a créée n’est plus dans l’entreprise. Est-ce qu’on peut le migrer vers ce fameux Power Automate ? » — on me pose souvent ce genre de question. Des agrégations quotidiennes et des générations de documents construites en VBA fonctionnent encore aujourd’hui dans de nombreuses entreprises, et le départ de leur auteur, ou l’actualité autour de l’abandon de VBScript, laissent de nombreux responsables inquiets quant à l’avenir de leurs actifs VBA.

Disons-le d’emblée : « migrer VBA vers Power Automate » est, plus précisément, la combinaison de plusieurs histoires distinctes — réécrire une partie du VBA en script Office et l’appeler depuis Power Automate, remplacer une autre partie par un connecteur, et laisser le reste en VBA. Il n’existe aucun mécanisme permettant d’exécuter une macro VBA telle quelle dans un flux cloud. Cet article détaille quels traitements peuvent migrer vers quoi, et quelles parties doivent rester en VBA, en s’appuyant sur la documentation de référence de Microsoft Learn à chaque étape.

1. La conclusion d’abord

• Vous ne pouvez pas exécuter une macro VBA directement depuis un flux cloud Power Automate. Le connecteur Excel Online (Business) peut manipuler les fichiers .xlsm, mais il ne peut pas exécuter les macros qu’ils contiennent — seuls les scripts Office peuvent être exécutés de cette manière.¹
• Les scripts Office ne remplacent pas complètement VBA. Ils sont réservés à Excel et ne permettent ni de piloter d’autres applications Office, ni de répondre à des événements, ni d’utiliser UserForm, ni de faire de l’intégration COM/OLE, ni d’accéder à des fichiers locaux.²³
• À l’inverse, un traitement qui reste entièrement à l’intérieur du classeur — mise en forme, agrégation, recopie — mérite largement d’être converti en script Office. Combiné à Power Automate, cela permet des exécutions planifiées ou des déclenchements sur réception d’un e-mail ou d’un formulaire, offrant ce type d’automatisation « qui fonctionne sans jamais ouvrir Excel » que VBA n’a jamais pu atteindre.²
• Pour quelque chose d’aussi simple qu’ajouter ou lire des lignes d’un tableau, vous pouvez le traiter directement avec les actions du connecteur Excel Online (Business), sans écrire de script du tout — vérifiez simplement au préalable les contraintes (un tableau est requis, le plafond par défaut est de 256 lignes, la taille de fichier est limitée à 25 Mo, etc.).⁴
• Pour un traitement qui nécessite absolument VBA, il existe l’option de lancer le VBA existant tel quel avec l’action Run Excel macro d’un flux de bureau. Cela permet d’automatiser le lancement et les étapes environnantes sans réécrire le VBA.⁵
• Les scripts Office nécessitent une licence Microsoft 365 commerciale ou destinée à l’éducation, plus OneDrive for Business. VBA ne nécessite aucune licence supplémentaire : c’est donc un prérequis à régler avant de décider d’une migration.⁶²

2. Clarifier les relations entre VBA, les scripts Office et Power Automate

Commençons par clarifier les acteurs en présence — les noms se ressemblent beaucoup, et c’est la principale source de confusion.

flowchart TB
    subgraph Cloud[Côté cloud]
        CF[Power Automate<br/>flux cloud]
        Conn[Connecteur Excel<br/>Online Business]
        OS[Script Office<br/>automatisation Excel en TypeScript]
        CF --> Conn
        Conn -- Run script --> OS
        Conn -- Ajout/lecture/mise à jour des lignes --> Table[Tableau Excel]
    end
    subgraph Desktop[Côté bureau]
        DF[Power Automate<br/>flux de bureau]
        VBA[Macro VBA existante]
        DF -- Run Excel macro --> VBA
    end
    CF -- Appelle --> DF
    OS -.-> Book[Classeur sur OneDrive / SharePoint]
    VBA -.-> LocalBook[Classeur sur disque local / serveur de fichiers]

• Les scripts Office (Office Scripts) sont une fonctionnalité de script qui automatise Excel en TypeScript. Ils fonctionnent sur Excel sur le web, Excel pour Windows (version 2210 et ultérieure) et Excel pour Mac, et peuvent être appelés depuis un flux cloud Power Automate. La différence fondamentale avec VBA est que VBA est conçu pour le bureau, tandis que les scripts Office sont conçus pour le cloud et l’usage multiplateforme.²⁶
• Le connecteur Excel Online (Business) exploite depuis un flux cloud les fichiers Excel situés sur OneDrive for Business ou SharePoint. Il propose des actions d’opération sur les lignes d’un tableau, ainsi qu’une action « Run script » (exécution de script) qui exécute un script Office.⁷
• Les flux de bureau (Power Automate for desktop) sont une solution de RPA qui pilote des applications sous Windows. Son ensemble d’actions Excel comprend une action permettant d’exécuter une macro VBA.⁵

Ce que VBA sait faire et que les scripts Office ne savent pas faire

C’est le point le plus important pour la décision de migration. Voici une synthèse organisée autour du document « Differences between Office Scripts and VBA macros » de Microsoft Learn.²

L’appel de services web externes demande aussi de la vigilance. Les scripts Office prennent en charge de manière limitée les appels externes, mais lorsqu’ils sont exécutés via Power Automate, tout appel d’API externe (fetch) depuis l’intérieur du script échoue. L’intégration externe doit être conçue au niveau des connecteurs du flux ou de son action HTTP, et non dans le script lui-même.²⁶ Notez toutefois que l’action HTTP générique permettant d’appeler une API quelconque est traitée comme un connecteur premium, ce qui signifie qu’une licence Microsoft 365 seule ne suffit pas à la débloquer.⁸ Privilégiez un connecteur standard partout où il en existe un pour le service à intégrer, et si l’appel d’une API propriétaire est incontournable, intégrez le coût supplémentaire d’une licence premium à votre décision de migration.

Beaucoup de lecteurs, en découvrant cette liste, auront l’impression que « pratiquement toute notre macro y figure ». C’est une réaction légitime — une macro VBA qui a grossi au fil des années inclut couramment l’envoi de courriers via Outlook, le parcours d’une arborescence de dossiers et la saisie via un UserForm. Mais avant de baisser les bras, essayez de décomposer le traitement. Pour une macro qui « collecte des fichiers dans un dossier, met en forme un classeur, puis l’envoie par e-mail », la collecte de fichiers et l’envoi d’e-mail sont exactement le genre de tâches où les connecteurs Power Automate excellent, et si l’on convertit uniquement la partie mise en forme du classeur en script Office, l’ensemble peut migrer — ce schéma revient plus souvent qu’on ne le penserait.

3. Un tableau de décision — choisir parmi cinq options selon le cas d’usage

La cible de migration ne se limite pas à « convertir en script Office ». En pratique, il faut raisonner selon ces cinq options.

Le logigramme ci-dessous détermine à peu près lequel choisir.

flowchart TD
    Start[Choisir une macro VBA] --> Q1{Le traitement reste-t-il<br/>entièrement dans le classeur ?}
    Q1 -- Non --> Q2{La partie hors Excel peut-elle<br/>être remplacée par un connecteur ?<br/>ex. envoi d'e-mail, collecte de fichiers}
    Q2 -- Oui --> Split[Décomposer le traitement :<br/>partie Excel -> script Office<br/>reste -> connecteurs du flux]
    Q2 -- Non<br/>UI d'une autre app / automatisation COM --> Q5{Peut-on se permettre<br/>de réécrire le VBA ?}
    Q1 -- Oui --> Q3{Le classeur peut-il résider<br/>sur OneDrive/SharePoint ?}
    Q3 -- Oui --> Q4{S'agit-il seulement<br/>d'opérations sur les lignes d'un tableau ?}
    Q4 -- Oui --> C3[Traiter directement avec<br/>le connecteur Excel Online Business]
    Q4 -- Mise en forme/plusieurs feuilles/<br/>logique impliquée --> C2[Convertir en script Office<br/>et l'exécuter avec Run script]
    Q3 -- Non<br/>serveur interne uniquement --> C4[Lancer le VBA existant<br/>tel quel via un flux de bureau]
    Q5 -- Non --> C4
    Q5 -- Oui/performance ou tests nécessaires --> C5[Reconstruire en .NET]
    Split --> C2

À noter : l’option (4) n’est pas une « destination finale » de la migration — c’est du maintien en vie. La dépendance du VBA sous-jacent à une seule personne et l’absence de gestion de version demeurent exactement telles quelles. Malgré cela, c’est suffisamment utile comme solution provisoire : automatiser d’abord le lancement pour éliminer les erreurs d’exécution manuelle, et utiliser ce répit pour transférer progressivement le contenu du VBA vers des scripts Office ou du .NET.

4. Modèles d’implémentation — l’action Run script et les limites des connecteurs

Exécuter le script (Run script)

Pour exécuter un script Office depuis un flux cloud, on utilise deux actions du connecteur Excel Online (Business). Run script est destinée aux scripts stockés sur OneDrive (l’emplacement par défaut), et Run script from SharePoint library aux scripts enregistrés dans une bibliothèque SharePoint d’équipe.⁷

Une configuration typique ressemble à ceci.

1. Déclencheur : planification (Recurrence), réception d’un e-mail, soumission d’un formulaire, etc.
2. Identifier le classeur cible via le connecteur OneDrive / SharePoint
3. Exécuter le script Office avec Run script et récupérer sa valeur de retour
4. Utiliser la valeur de retour pour envoyer une notification Teams ou un e-mail

Un script peut recevoir des paramètres et renvoyer une valeur, ce qui permet un échange de données dans les deux sens — par exemple, « transmettre une clé de recherche depuis le flux, faire renvoyer par le script les données correspondantes du classeur, puis en faire un e-mail côté flux ». Notez que la fonctionnalité « planifier l’exécution des scripts » qui existait autrefois dans Excel lui-même est actuellement désactivée, et l’exécution planifiée est désormais recommandée sous forme de flux Power Automate.¹¹

Vérifier d’abord les limites

Le plus grand piège lors d’une migration depuis VBA est l’ensemble des limites propres à l’exécution dans le cloud — des plafonds qui n’existaient pratiquement pas pour du VBA de bureau sont bien présents ici.

Si vous manipulez directement un tableau via le connecteur Excel Online (Business), vérifiez également ces points supplémentaires.⁴

• Les opérations sur les lignes supposent un tableau. Des actions comme « Add a row into a table » (ajouter une ligne à un tableau) et « Get a row » (obtenir une ligne) sont conçues autour de la désignation d’un tableau (un ListObject) — elles ne peuvent pas cibler des données simplement écrites dans une plage de cellules ordinaire. Une feuille héritée de l’époque VBA qui « commence à écrire des données quelque part autour de la cellule A1 » doit être convertie en tableau avant la migration.
• List rows present in a table ne renvoie par défaut que 256 lignes au maximum. Activez la pagination pour récupérer toutes les lignes. Les colonnes renvoyées sont elles aussi plafonnées par défaut aux 500 premières.
• L’écriture peut prendre jusqu’à environ 30 secondes avant d’être répercutée. Un fichier peut aussi rester verrouillé jusqu’à 6 minutes après utilisation par le connecteur.
• Les écritures simultanées depuis plusieurs clients ne sont pas prises en charge. Faire écrire un flux dans un classeur resté ouvert dans Excel de bureau, par exemple, est source de conflits et d’incohérences.
• Les formats pris en charge sont .xlsx et .xlsb (classeur binaire). Le format .xlsm ne peut être sélectionné que via le navigateur de fichiers de l’action Run script ; son utilisation dans d’autres actions nécessite de spécifier directement l’ID du fichier. Mais comme indiqué plus haut, les macros VBA qu’il contient ne s’exécuteront pas. Un fichier .xlsm contenant des contrôles ActiveX ou des contrôles de formulaire peut ne pas fonctionner du tout avec le connecteur : une vérification préalable est indispensable.¹

Si vous essayez de convertir telle quelle une « macro qui agrège des centaines de milliers de lignes chaque nuit » en script Office, vous vous heurterez de front à la limite de 5 Mo et au délai d’expiration de 120 secondes. Il est plus sain d’orienter dès le départ ce type de volumétrie vers le .NET (option 5).

Lancer VBA depuis un flux de bureau

Si vous conservez le VBA tel quel, ouvrez le classeur avec Launch Excel d’un flux de bureau, puis exécutez la macro avec l’action Run Excel macro, en spécifiant le nom de la macro (les arguments étant séparés par des points-virgules). Pour utiliser une macro du classeur de macros personnelles (PERSONAL.XLSB), il faut activer « Nest under a new Excel process » (imbriquer sous un nouveau processus Excel) et « Load add-ins and macros » (charger les compléments et les macros) dans les paramètres avancés de Launch Excel.⁵

Déclencher un flux de bureau depuis un flux cloud nécessite une machine enregistrée et une connexion de flux de bureau ; l’exécution supervisée requiert une licence utilisateur Power Automate Premium pour le propriétaire de la connexion, et l’exécution non supervisée requiert une licence Power Automate Process sur la machine (ou l’ancien module complémentaire Unattended RPA).⁹¹⁰ La conception d’ensemble des flux de bureau — gestion des erreurs, prérequis de l’exécution non supervisée, etc. — est traitée plus en détail dans un article séparé, « Automatiser des processus métier avec Power Automate — choisir entre flux cloud et flux de bureau, et concevoir la gestion des erreurs ».

5. Licences et prérequis

Le fait que les scripts Office ne soient pas « une fonctionnalité gratuite incluse dans Excel » est un point à vérifier tôt dans la décision de migration.

• L’utilisation ou la création de scripts Office nécessite une licence d’abonnement Microsoft 365 commerciale ou destinée à l’éducation (Office 365 Business / Business Premium / ProPlus / ProPlus for Devices / A3 / A5 / E1 / E3 / E5 / F3) et OneDrive for Business. L’activation des liens de partage à l’échelle de l’organisation, ainsi qu’une connexion Internet avec les expériences connectées activées, sont également des prérequis.⁶
• Utiliser les scripts Office depuis Power Automate nécessite également une licence professionnelle Microsoft 365. E1 et F3 permettent d’exécuter des scripts via Power Automate, mais ne permettent pas d’utiliser l’intégration Power Automate propre à Excel (des fonctionnalités comme « Automatiser mon travail » dans Excel).⁷
• Les scripts Office sur Microsoft 365 pour particuliers/famille sont encore en préversion et nécessitent une inscription au programme Microsoft 365 Insider — cela ne peut pas être présupposé comme base pour un usage professionnel.⁶
• Côté client, ils fonctionnent sur Excel sur le web, Excel pour Windows (version 2210 et ultérieure) et Excel pour Mac.⁶
• VBA, à l’inverse, est intégré à la version bureau d’Excel et ne nécessite aucune licence particulière.²

Autrement dit, dans un environnement où « notre Excel interne est une licence perpétuelle (achetée une fois) et nous n’avons pas d’abonnement Microsoft 365 », l’option des scripts Office n’existe tout simplement pas au départ. Dans ce cas, la cible de migration se réduit à l’automatisation du lancement via un flux de bureau, ou à une reconstruction en .NET.

Les différences en matière de sécurité méritent aussi d’être comprises. Une macro VBA s’exécute avec les mêmes privilèges qu’Excel, ce qui lui donne accès à l’ensemble du poste de travail ; un script Office ne peut jamais accéder qu’au classeur, et le jeton d’authentification de l’utilisateur connecté n’est jamais transmis au script. Les administrateurs peuvent contrôler, au niveau du locataire ou du groupe, si les scripts Office peuvent être utilisés du tout, et s’ils peuvent l’être depuis Power Automate. Pour les services informatiques qui ont eu du mal à maîtriser la sécurité des macros, cette facilité de gouvernance est l’un des véritables avantages de la migration.²

6. Comment aborder la migration — inventaire, classification, migration progressive

Je recommande de mener la migration proprement dite selon ces trois étapes.

Étape 1 : l’inventaire. Dressez la liste des classeurs, des macros qu’ils contiennent et de qui en assure la gestion. La même procédure que celle utilisée pour se préparer à l’abandon de VBScript s’applique ici ; consultez donc l’article séparé « Guide d’audit VBA et outils internes en vue de l’abandon de VBScript » pour la marche à suivre concrète. Il est fréquent de découvrir, une fois l’inventaire terminé, que 20 à 30 % des macros ne sont déjà plus utilisées, et le simple fait de les exclure de la migration réduit immédiatement la charge de travail.

Étape 2 : la classification. Faites correspondre les macros restantes au tableau de décision du chapitre 3. L’astuce ici est de décomposer chaque macro par unité de traitement plutôt que de la considérer comme un tout indivisible. Une macro qui « collecte des fichiers -> met en forme -> envoie un e-mail » peut être décomposée en une combinaison de (3) le connecteur, plus (2) un script Office, plus un connecteur e-mail. Seules les parties qui restent dépendantes de VBA même après décomposition — saisie interactive via UserForm, opérations COM sur d’autres applications, etc. — deviennent candidates pour (1) rester en place ou (4) passer par un flux de bureau.

Étape 3 : migrer par étapes. Ne réécrivez pas toutes les macros d’un coup — établissez des priorités.

1. Commencez par les macros qui s’exécutent fréquemment et restent entièrement à l’intérieur du classeur. Le gain de la migration y est important, et c’est aussi une bonne façon de se familiariser avec les scripts Office. VBA et TypeScript sont des langages différents, mais les scripts Office disposent aussi d’un enregistreur d’actions (Action Recorder), qui permet de construire une première ébauche avec une sensation très proche de l’enregistreur de macros de VBA.²
2. Faites tourner en parallèle le flux migré avec la version d’origine, en croisant les résultats avec la version VBA pendant un certain temps. C’est là que l’on repère les écarts causés par exemple par le passage à un tableau ou par des différences de format de date.
3. Pour tout ce que vous décidez de garder en VBA, « gardez-le sous gestion ». Documentez une procédure claire et un responsable identifié, et lorsque c’est possible, orientez-le vers un lancement via un flux de bureau afin de conserver un journal d’exécution.

La question plus large de l’avenir de VBA, et la façon d’aborder les cas où continuer à utiliser VBA reste pertinent, est traitée dans « Qu’est-ce que VBA ? Ses limites, son avenir, et quand et comment le remplacer de façon réaliste » ; une comparaison des approches pour faire migrer la génération de documents vers .NET est traitée dans « Comment construire la sortie de documents Excel — COM / Open XML / modèles ». Et si vous envisagez de piloter Excel depuis .NET via COM, il existe un problème classique où le processus reste actif après coup ; consultez donc aussi « Le problème d’EXCEL.EXE qui reste actif dans l’automatisation Excel en C# — modèles de libération des références COM et quand les remplacer ».

7. Conclusion

La réponse à la question « peut-on migrer de VBA vers Power Automate » est : « on ne peut pas transposer une macro entière telle quelle, mais en décomposant le traitement, la majeure partie a un endroit où aller ».

Le traitement qui reste entièrement à l’intérieur du classeur devient un script Office appelé depuis un flux cloud ; les opérations simples sur les lignes vont directement à un connecteur ; tout ce qui implique une intégration avec d’autres applications ou un UserForm reste en VBA ou est maintenu en vie via un flux de bureau ; et les données en gros volume ou la logique complexe sont orientées vers .NET. Effectuez ce tri en amont, et la migration n’a pas besoin de se faire d’un seul coup — vous pouvez avancer progressivement, en commençant par les macros les plus fréquemment exécutées.

À l’inverse, si vous sautez le tri et commencez directement par « réécrivons tout en script Office », vous vous heurterez successivement au mur des événements et des UserForm, aux limites de 5 Mo / 120 secondes, et à l’obligation d’avoir un tableau, et l’effort s’enlisera. La réussite d’une migration tient bien plus à l’inventaire et à la classification effectués avant de commencer qu’à la dextérité de réécriture du code. Traiter les actifs VBA comme quelque chose à « trier et mettre à profit », plutôt que comme « quelque chose à jeter un jour », finit par être l’approche la plus économique.

Articles liés

• Qu’est-ce que VBA ? Ses limites, son avenir, et quand et comment le remplacer de façon réaliste
• Guide d’audit VBA et outils internes en vue de l’abandon de VBScript
• Automatiser des processus métier avec Power Automate — choisir entre flux cloud et flux de bureau, et concevoir la gestion des erreurs
• Comment construire la sortie de documents Excel — COM / Open XML / modèles
• Le problème d’EXCEL.EXE qui reste actif dans l’automatisation Excel en C# — modèles de libération des références COM et quand les remplacer

Domaines de conseil associés

Le cabinet KomuraSoft LLC (合同会社小村ソフト) accompagne aussi bien l’inventaire des processus existants pilotés par Excel/VBA que la conception d’une migration progressive vers Power Automate, les scripts Office et .NET, en s’appuyant sur l’existant.

• Réutilisation des actifs existants et accompagnement à la migration
• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Une macro VBA existante peut-elle être exécutée directement depuis Power Automate ?

Pas depuis un flux cloud. Le connecteur Excel Online (Business) peut manipuler le fichier .xlsm lui-même, mais il ne peut pas exécuter les macros qu'il contient — seuls les scripts Office peuvent être exécutés de cette manière. Un flux de bureau (Power Automate for desktop), en revanche, dispose d'une action Run Excel macro qui permet d'exécuter tel quel la macro VBA d'un classeur ouvert avec Launch Excel. Si vous souhaitez simplement automatiser le lancement de la macro sans modifier son code VBA, passer par un flux de bureau est l'option réaliste.

Un script Office remplace-t-il complètement VBA ?

Non. Les scripts Office sont réservés à Excel et ne peuvent pas piloter d'autres applications Office comme Word ou Outlook. Comme un script ne peut accéder qu'au classeur, il ne peut ni accéder aux fichiers locaux ni faire d'intégration COM/OLE, et il n'existe pas de modèle événementiel comme Workbook_Open ni de boîtes de dialogue personnalisées construites avec UserForm. En revanche, un traitement qui reste entièrement à l'intérieur du classeur — mise en forme, agrégation, recopie — peut être converti en script Office, ce qui permet ensuite de le déclencher sur planification ou sur réception d'un e-mail ou d'un formulaire via Power Automate. La façon exacte de voir les choses est que les deux ne se substituent pas l'un à l'autre : ils couvrent simplement des périmètres différents.

Quelle licence est nécessaire pour utiliser les scripts Office ?

Une licence Microsoft 365 commerciale ou destinée à l'éducation (Office 365 Business / Business Premium / ProPlus / E1 / E3 / E5 / F3 / A3 / A5), plus OneDrive for Business. Exécuter un script Office depuis Power Automate nécessite également une licence professionnelle Microsoft 365 ; E1 et F3 permettent d'exécuter des scripts via Power Automate mais ne permettent pas d'utiliser les fonctionnalités d'intégration Power Automate à l'intérieur d'Excel lui-même. Cela contraste avec VBA, qui est inclus en standard dans la version bureau d'Excel et ne nécessite aucune licence supplémentaire : il faut donc vérifier les licences de son organisation avant de décider d'une migration.

Le connecteur Excel Online (Business) suffit-il à lui seul pour automatiser un traitement ?

Pour un traitement simple, oui, mais de nombreuses limites sont à surveiller. L'ajout, la récupération, la mise à jour ou la suppression de lignes suppose que la plage soit déjà un tableau Excel (un ListObject) ; List rows present in a table ne renvoie par défaut que 256 lignes au maximum et nécessite d'activer la pagination pour aller au-delà. La taille de fichier est plafonnée à 25 Mo, celle d'une requête à 5 Mo, et l'écriture peut prendre jusqu'à environ 30 secondes avant d'être répercutée. Une répartition pratique consiste à utiliser directement le connecteur pour lire et écrire quelques lignes dans un tableau, et à recourir à un script Office pour la mise en forme des cellules ou tout ce qui s'étend sur plusieurs feuilles.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.