Qu'est-ce que VBA ? - Ses contraintes, son avenir, quand le remplacer et des schémas de migration réalistes

Dans les consultations autour de VBA, ces questions reviennent souvent, mélangées les unes aux autres.

• Qu’est-ce que VBA, au juste ?
• On dit que les macros sont dangereuses — faut-il arrêter de les utiliser ?
• VBA va-t-il devenir inutilisable dans un avenir proche ?
• Faut-il tout migrer vers Office Scripts ou Power Automate ?
• Faut-il conserver ou abandonner les actifs .xlsm et Access existants ?
• Peut-on faire tourner Excel dans un traitement batch nocturne ou sur un serveur ?

Ce n’est pas un sujet qu’une seule réponse suffit à régler proprement. Ce qu’il faut regarder en premier n’est pas le fait qu’une technologie soit récente ou ancienne, mais où elle s’exécute, qui l’utilise, si Excel / Access lui-même constitue l’interface, et si l’exécution se fait sans surveillance.

Cet article organise le sujet dans cet ordre : ce qu’est VBA, où se situent ses contraintes, s’il va devenir inutilisable, dans quels cas il faut le remplacer, et comment mener une migration par étapes de façon réaliste. Le contenu s’appuie sur les informations officielles de Microsoft vérifiables à la date de mars 2026.¹²³⁴⁵

1. D’abord, la conclusion

Voici d’abord les conclusions, mises bout à bout.

• VBA est un langage événementiel destiné à étendre les applications Office de bureau. C’est une technologie qui suppose une exécution à l’intérieur d’Excel, Word, PowerPoint, Access, etc.¹
• Au moins jusqu’en mars 2026, aucune annonce officielle claire de Microsoft n’indique que « VBA lui-même sera abandonné prochainement ». Ce qui se produit actuellement ressemble moins à une « suppression brutale et totale » qu’à un changement où les lieux où VBA peut être utilisé et ses conditions préalables se sont clarifiés.¹²³⁴
• Concrètement, Excel pour le web ne permet ni de créer, ni d’exécuter, ni de modifier du VBA. De plus, les macros contenues dans des fichiers provenant d’Internet sont bloquées par défaut.²³
• La vraie question aujourd’hui n’est donc pas « faut-il jeter tout le VBA », mais quelles zones garder en VBA et lesquelles faire sortir.
• En particulier, les traitements qui nécessitent une exécution sans surveillance, une exécution côté serveur, une utilisation multi-utilisateurs, une compatibilité navigateur, une distribution centralisée ou un audit strict ne devraient pas reposer uniquement sur VBA. Microsoft lui-même ne recommande ni ne prend en charge l’automatisation côté serveur d’Office.⁶
• Il n’existe pas une seule destination de remplacement. La répartition réaliste est la suivante : si Excel reste en place, faire sortir le traitement vers des DLL .NET ou un processus séparé ; pour les flux métier sur Microsoft 365, Office Scripts + Power Automate ; pour une extension multiplateforme, Office Add-ins ; et si Excel n’est plus vraiment l’interface, migrer vers une application Windows ou une application Web.⁴⁵⁶

En résumé, l’approche la plus pragmatique consiste à voir VBA non pas comme « une technologie sur le point de mourir », mais comme « une technologie dont la juste place est désormais bien définie ».

2. Qu’est-ce que VBA ?

VBA signifie Visual Basic for Applications ; c’est une variante de Visual Basic fournie avec Microsoft Office. La documentation officielle de Microsoft la décrit également comme un langage de programmation événementiel destiné à étendre les applications Office.¹⁷

Le point important ici est qu’il est plus proche de la réalité de voir VBA non pas comme une plateforme de développement d’applications généraliste, mais comme un langage d’extension inséré à l’intérieur des applications Office.

Dans Excel, par exemple, il opère à proximité d’objets tels que ceux-ci.

• Workbook
• Worksheet
• Range
• Boutons et formulaires
• Événements à l’ouverture du classeur, à l’enregistrement, ou lors du changement d’une cellule

Autrement dit, la force de VBA est d’être extrêmement proche des écrans, des rapports et de la structure des classeurs d’Excel et d’Access. L’utilisateur ouvre Office sur son poste de bureau, clique sur un bouton, traite des données issues de fichiers locaux ou de dossiers partagés, et produit directement un rapport. Pour ce type d’« automatisation qui se termine entièrement au poste de l’utilisateur », VBA conserve aujourd’hui encore de vrais atouts.¹

Inversement, le périmètre naturel de VBA n’a jamais été, dès l’origine, les serveurs, les navigateurs, le mobile ou les systèmes Web multi-locataires (multi-tenant).

3. Pourquoi est-il encore utilisé aujourd’hui ?

La raison pour laquelle VBA reste présent sur le terrain aujourd’hui n’est pas simplement « il est ancien et subsiste par inertie ».

D’abord, Excel et Access ont tendance à absorber non seulement des données, mais la procédure métier elle-même.

• L’apparence des rapports
• Les paramètres d’impression
• Les contrôles de saisie
• L’ordre des traitements mensuels
• Les règles d’exception propres à chaque service
• Les modes opératoires auxquels le terrain s’est habitué depuis des années

Lors d’un transfert vers un autre système, un simple « portage de code » ne suffit pas pour cela. L’apparence, l’exploitation, les exceptions et le fonctionnement au quotidien forment un tout, si bien que les actifs VBA portent bien plus de spécifications qu’il n’y paraît.

Par ailleurs, comme VBA est proche du modèle objet d’Office, peu d’étapes suffisent pour manipuler l’Excel qui se trouve devant l’utilisateur et en renvoyer le résultat. Cette proximité compte aussi lorsqu’on envisage un successeur : il ne suffit pas nécessairement de tout réécrire dans une technologie plus récente pour que le sujet soit clos.

En pratique, il est naturel de raisonner ainsi.

• Si Excel continue d’être l’interface, conserver une partie du VBA a de la valeur
• Si Excel n’a besoin de servir qu’à l’entrée/sortie, la logique interne est facile à faire sortir
• Si Excel lui-même n’est plus vraiment l’interface d’origine, il devient un candidat à une refonte

4. Les principales contraintes de VBA

4.1 Il suppose un environnement de bureau

C’est la contrainte la plus importante. VBA est, fondamentalement, une technologie qui s’exécute à l’intérieur de la version bureau d’Office.

Selon les informations officielles de Microsoft, Excel pour le web ne permet ni de créer, ni d’exécuter, ni de modifier du VBA ; on peut ouvrir et modifier un classeur contenant des macros, mais on ne peut pas exécuter le VBA.²⁸

Cela suffit déjà à rendre VBA peu compatible avec des exigences comme celles-ci.

• Tout doit se terminer dans le navigateur
• La même extension doit fonctionner sur Mac / iPad / Web
• Les administrateurs veulent une distribution centralisée
• On ne veut pas dépendre de l’application de bureau Excel en local

Microsoft lui-même, dans la documentation de VBA, oriente les lecteurs vers Office Add-ins pour créer des extensions destinées à plusieurs plateformes.⁹⁵

4.2 Une friction importante côté sécurité et distribution

Une grande partie de la raison pour laquelle on croit à tort que VBA « n’est plus utilisable » tient en réalité au renforcement de la sécurité.

Microsoft bloque désormais par défaut les macros VBA contenues dans des fichiers provenant d’Internet. Ouvrir tel quel un .xlsm reçu en pièce jointe ou téléchargé ne suffit plus à exécuter les macros aussi simplement qu’auparavant.³

C’est la bonne direction du point de vue de la sécurité. Mais du côté de l’exploitation, cela génère des frictions supplémentaires :

• Distribué en pièce jointe, cela ne fonctionne pas
• Un modèle téléchargé depuis un site externe ne fonctionne pas
• Le comportement via OneDrive / SharePoint / le réseau est difficile à cerner
• L’indication « veuillez activer les macros » devient un point faible de l’exploitation

Autrement dit, les problèmes de VBA ne se limitent pas aux « fonctionnalités du langage » : ils touchent aussi à la conception de la distribution et de la confiance.

4.3 Le mur du 32 bits / 64 bits

Office existe en version 32 bits et en version 64 bits, et la version par défaut est 64 bits dans Office 2019 et Microsoft 365.⁷

De ce fait, parmi le code VBA ancien, celui qui appelle des API Windows via Declare en particulier peut ne pas fonctionner tel quel dans un environnement 64 bits. Microsoft indique également qu’il faut absorber les différences entre 32 bits et 64 bits à l’aide de PtrSafe, LongPtr, LongLong, etc.⁷

Ce qui est pénible ici, c’est que ce ne sont pas seulement le code, mais aussi ces dépendances qui deviennent facilement problématiques en même temps.

• D’anciens COM / ActiveX / OCX
• Des DLL externes qui supposent le 32 bits
• Des composants qui supposent un enregistrement dans le registre
• Des références Office désalignées

Autrement dit, une migration VBA se révèle très souvent moins une réécriture du langage qu’un démêlage de la bitness d’Office et des dépendances externes.

4.4 Peu adapté à l’exécution sans surveillance ou côté serveur

Ce point est assez important. Microsoft indique explicitement qu’il ne recommande ni ne prend en charge l’automatisation côté serveur des applications Office. Office est conçu en partant du principe d’un bureau interactif et d’un profil utilisateur, et dans un environnement sans surveillance, cela peut provoquer instabilité ou blocages (deadlocks).⁶

C’est pourquoi des configurations comme celles-ci penchent du côté dangereux.

• Lancer Excel depuis un service Windows
• Automatiser Office depuis ASP.NET ou DCOM
• Faire tourner indéfiniment, dans le Planificateur de tâches, un Excel invisible
• Confier entièrement la génération de rapports à un Excel exécuté sur un serveur

Il arrive que « ça fonctionne de temps en temps ». Mais fonctionner et constituer une configuration prise en charge sont deux choses différentes.

Si l’exécution sans surveillance est nécessaire, le premier suspect à examiner n’est pas VBA, mais la configuration qui fait tourner l’application Excel elle-même.

4.5 Souvent désavantagé en maintenabilité, testabilité et gestion des différences

Le code VBA a tendance à rester enfermé à l’intérieur des classeurs ou des fichiers Access. Il en résulte que des problèmes comme ceux-ci apparaissent facilement.

• On ne sait plus clairement quel fichier fait autorité
• Les responsabilités se dispersent entre formulaires, feuilles et modules standards
• Les références et les dépendances ActiveX divergent d’un environnement à l’autre
• La revue de code et la vérification des différences deviennent difficiles
• Les tests unitaires sont difficiles à écrire
• Les adresses de cellules Excel elles-mêmes finissent par tenir lieu de spécification

Ce n’est pas un problème propre au langage VBA, mais un problème de structure : « conserver la logique métier à l’intérieur d’un fichier Office ». Pour une petite automatisation, cela ne pose pas de grand problème, mais dès que le tout se transforme en système métier, l’effet se fait sentir soudainement.

4.6 Une vigilance particulière est nécessaire en cas de dépendance à VBScript

En 2025, le Microsoft 365 Developer Blog a annoncé que l’abandon progressif de VBScript sous Windows peut aussi affecter les projets VBA. En particulier, les cas qui exécutent un .vbs externe et les cas qui dépendent de la référence VBScript.RegExp sont concernés.¹⁰

Dans le même temps, Microsoft avance également sur ce point en intégrant par défaut la classe RegExp dans VBA, dans la version Office pour Windows à partir de Microsoft 365 Version 2508 (Build 19127.20154).¹⁰

Ce qui compte ici, c’est que l’abandon de VBScript et l’abandon de VBA ne sont pas la même histoire. Il ne s’agit pas de la disparition de VBA lui-même, mais plutôt du fait qu’il faut revoir une partie des dépendances externes qui étaient rattachées à VBA — c’est la compréhension la plus exacte.

5. VBA va-t-il devenir inutilisable ?

D’abord, il ne s’agit pas d’une histoire où « tout deviendrait inutilisable dès demain ». Mais ce n’est pas non plus l’époque où l’on peut « utiliser VBA partout, pour tout ».

Au minimum, en lisant les informations officielles de Microsoft, la tendance qui se dégage clairement aujourd’hui est la suivante.

• VBA, en tant qu’extension d’Office de bureau, continue d’exister¹
• Côté Web / multiplateforme, on utilise Office Scripts ou Office Add-ins selon le cas⁴⁵⁹
• La sécurité de la distribution des macros est traitée plus strictement qu’avant³
• Des composants périphériques comme la dépendance à VBScript peuvent subir des effets à l’avenir¹⁰

De plus, à propos d’Office Scripts, Microsoft indique clairement que VBA est centré sur le bureau, tandis qu’Office Scripts est destiné à des solutions sécurisées, multiplateformes et basées sur le cloud. Dans le même temps, Microsoft explique aussi qu’à l’heure actuelle, le périmètre des fonctionnalités Excel disponibles côté client de bureau reste plus large avec VBA.⁴

En mettant ces deux points côte à côte, on obtient une vision très pragmatique.

• Pour une manipulation approfondie d’Excel de bureau, le périmètre de VBA reste encore plus large
• Pour le navigateur / M365 / les flux de travail partagés, Office Scripts et les Add-ins sont plus naturels
• Donc, la réponse n’est ni « il suffit de tout basculer vers Office Scripts », ni « il suffit de garder VBA au centre pour toujours »

Il est naturel de considérer l’avenir de VBA comme une clarification de ses limites plutôt qu’une disparition.

6. Cas où il faut remplacer / cas où ce n’est pas nécessaire

Voici d’abord un tableau de décision, sommaire mais utile.

Ce qui compte dans ce tableau, c’est que l’axe de décision du remplacement n’est pas « VBA est ancien ». Ce qu’il faut réellement regarder, ce sont l’environnement d’exécution, l’exploitation, la distribution, les dépendances, l’audit et l’extensibilité.

7. Destinations de remplacement réalistes

7.1 Garder Excel et ne faire sortir que l’intérieur vers .NET ou un processus séparé

L’option la plus réaliste et la moins sujette à l’échec est celle-ci.

• L’entrée pour les écrans et les rapports reste Excel / Access
• Les boutons et les formulaires de saisie restent également en place pour l’instant
• En revanche, la logique métier, le HTTP, la cryptographie, le CSV / JSON, les calculs lourds et le traitement de fichiers sortent
• VBA se limite au rôle de « passerelle » et de « manipulation de l’interface »

L’avantage de cette configuration est qu’elle casse difficilement l’apparence et les habitudes de l’utilisateur. Plutôt qu’un remplacement complet, on peut avancer d’abord en allégeant les responsabilités.

Article connexe :

• Comment utiliser une DLL .NET 8 typée depuis VBA - exposition COM + génération d'un TLB avec dscom

« Avant de tout réécrire, commencer par faire sortir seulement les parties lourdes » est une approche très orientée terrain.

7.2 Pour l’exécution sans surveillance et la génération de rapports, privilégier la génération directe de fichiers plutôt que l’automatisation d’une application Office

Si l’objectif est de générer en masse des rapports Excel dans un traitement batch nocturne ou un service, le premier suspect à examiner n’est pas « VBA est-il ancien », mais le fait même de lancer l’application Excel.

Microsoft ne recommande pas l’automatisation d’Office côté serveur. Il recommande à la place de manipuler directement les fichiers Office, par exemple au format Open XML.⁶

Autrement dit, si le besoin est de

• produire un .xlsx
• sortir en grand volume des rapports standardisés
• convertir en PDF
• faire tourner cela dans un traitement batch nocturne

alors l’axe à choisir n’est pas faut-il piloter Excel, mais faut-il construire le fichier Excel.

Article connexe :

• Comment construire une sortie de rapport Excel - tableau de décision entre automatisation COM / Open XML / approche par modèle

7.3 Pour les flux métier sur Microsoft 365, Office Scripts + Power Automate

Si l’activité repose déjà largement sur OneDrive / SharePoint / Teams / Outlook / Forms, Office Scripts devient un candidat sérieux.

Microsoft décrit Office Scripts comme destiné à des solutions sécurisées, multiplateformes et basées sur le cloud. Combiné à Power Automate, il permet aussi d’automatiser le traitement Excel en prenant pour déclencheur un e-mail, un formulaire ou une planification.⁴¹¹

Cela dit, ce n’est pas non plus une solution universelle.

• Office Scripts ne prend pas en charge les événements de niveau Excel
• L’exécution repose fondamentalement sur un démarrage manuel ou un appel depuis Power Automate⁴
• L’intégration avec Power Automate nécessite une licence professionnelle Microsoft 365¹¹
• L’action Run script est soumise à des limites telles que 1 600 appels par utilisateur et par jour et 120 secondes de traitement synchrone¹²

Autrement dit, il est plus exact de voir Office Scripts non pas comme « un remplaçant de VBA », mais comme un composant d’automatisation sur M365.

7.4 Pour une extension multiplateforme, Office Add-ins

Pour étendre Word, Excel, Outlook, etc. sur Windows / Mac / iPad / navigateur, Office Add-ins est le premier candidat.

La documentation officielle de Microsoft explique également que les Office Add-ins peuvent être construits en HTML / CSS / JavaScript, fonctionnent sur plusieurs plateformes et se prêtent bien à une distribution centralisée.⁵

Cela convient par exemple à des exigences comme celles-ci.

• Relier Office à un portail interne ou à un système central
• Faire apparaître la même interface ou les mêmes commandes dans Outlook / Excel / Word
• Privilégier une distribution gérée par les administrateurs plutôt qu’une distribution de macros poste par poste
• S’éloigner du modèle de distribution local par fichier .xlsm

Le terrain de jeu diffère de celui de VBA, donc la sensation est assez différente de celle de coder à l’intérieur d’Excel. En contrepartie, l’exploitation et la distribution deviennent plus faciles à organiser.

7.5 Si Excel / Access lui-même n’est plus vraiment l’interface d’origine, migrer vers une application Windows ou Web

Une fois arrivé à ce stade, il est plus naturel de reconstruire sous forme d’application plutôt que de prolonger artificiellement VBA.

• Les transitions d’écran et le contrôle des droits se sont multipliés à l’excès
• La base de données, les journaux d’audit, les flux d’approbation et la gestion des utilisateurs sont devenus centraux
• Il existe une intégration avec des équipements externes ou des traitements de longue durée
• Les cellules ou les formulaires Excel en sont venus à tenir lieu de cahier des charges métier
• Le simple fait que la gestion d’état disparaisse à la fermeture du classeur devient pénible en soi

Dans ce cas, pour un outil métier pensé pour Windows, une application de bureau C# / .NET ; si la base d’utilisateurs ou de terminaux est large, une application Web permettra d’obtenir une structure plus naturelle.

8. Comment mener une migration par étapes

Le plus dangereux, dans le remplacement de VBA, est de vouloir tout reporter dès le départ sur une seule nouvelle technologie. En pratique, il est généralement plus sûr de progresser par étapes, dans l’ordre décrit ci-dessous.

8.1 D’abord, dresser un inventaire des actifs

Ce qu’il faut recenser en premier n’est pas tant le volume de code que les dépendances.

• Quels fichiers .xlsm / .xlam / .accdb / .mdb existent
• Lesquels constituent le point d’entrée de l’exploitation réelle
• Ce que contiennent les références
• Quels sont les Declare, les DLL externes, les COM / ActiveX / OCX
• Quelles sont les hypothèses en matière de 32 bits / 64 bits
• Quelle macro est utilisée par qui, selon quelle procédure
• Quels sont les résultats produits (Excel, CSV, PDF, impression, envoi d’e-mail, etc.)

Remplacer les éléments en laissant ce point flou entraîne plus tard des incidents du genre « la macro que personne ne pensait toucher était en fait encore vivante, seulement en fin de mois ».

8.2 Répartir le code par responsabilité

L’étape suivante consiste à découper non pas par fichier, mais par responsabilité.

• Manipulation de l’interface Excel / Access
• Entrées/sorties des feuilles
• Mise en page des rapports
• Règles métier
• E/S vers des API externes / fichiers / bases de données
• Traitement par lots
• Impression / distribution

Ce découpage permet de mieux voir ce qu’il faut conserver, ce qu’il faut alléger et ce qu’il faut faire sortir.

8.3 Déterminer la destination de remplacement pour chaque responsabilité

Voici une répartition facile à recommander.

• Interface et manipulation des feuilles : rester pour l’instant en VBA
• Logique métier : faire sortir vers des DLL .NET, un processus séparé ou un service
• Génération de rapports sans surveillance : privilégier Open XML ou la génération directe
• Flux de travail M365 : Office Scripts + Power Automate
• Interface multiplateforme : Office Add-ins
• Zones devenues des systèmes métier : séparer vers une application Windows / Web

Ce qui compte, c’est de ne pas unifier la migration vers une seule destination. Le contenu des actifs VBA mélange presque toujours plusieurs responsabilités.

8.4 Fixer d’abord les interfaces

Avant de commencer la migration, il vaut mieux décider au minimum les points suivants.

• Quelles sont les entrées
• Quelles sont les sorties
• Comment le résultat est renvoyé en cas d’erreur
• Quelles feuilles, quelles plages nommées, quels chemins de fichiers font office de contrat
• À quel moment le résultat est considéré comme définitif

Avancer sans avoir tranché ces points fait que les adresses de cellules elles-mêmes deviennent l’API, ce qui rend l’ensemble fragile.

8.5 Comparer en exploitation parallèle

Pour les rapports et les agrégations en particulier, il est plus sûr de ne pas basculer d’un coup.

• Faire produire des sorties en parallèle par l’ancienne version VBA et par la nouvelle implémentation
• Comparer les fichiers .xlsx / CSV / PDF produits
• Vérifier les écarts de dates, d’arrondis, de format et de zones d’impression
• Tester aussi les cas d’exception et les cas de données vides

Les incidents liés au remplacement de VBA surviennent le plus souvent non pas sous la forme « ça fonctionne ou pas », mais sous la forme d’un décalage silencieux dans les chiffres ou la mise en forme.

9. Erreurs fréquentes

9.1 Commencer par « VBA est ancien, donc tout vers Office Scripts »

Office Scripts est une option solide, mais Microsoft explique lui-même que VBA couvre un périmètre plus large de fonctionnalités Excel de bureau. De plus, Office Scripts ne prend pas en charge les événements de niveau Excel.⁴

L’idée de transposer telles quelles des macros fortement dépendantes d’Excel de bureau est donc risquée.

9.2 Continuer à lancer Excel lui-même alors que l’exécution est sans surveillance

C’est un cas assez fréquent. Tant que ça fonctionne, cela semble pratique, mais Microsoft ne recommande pas l’automatisation d’Office côté serveur.⁶

Pour un traitement batch nocturne ou un service, il est plus sûr de privilégier la construction du fichier Excel plutôt que le pilotage d’Excel.

9.3 Changer en même temps l’écran, les rapports et les règles métier

Ce qui est vraiment à craindre dans le remplacement de VBA n’est pas tant la conversion du code elle-même que la perte de spécifications métier en cours de route. Les feuilles Excel ou les formulaires Access contiennent souvent beaucoup de règles opérationnelles qui ne sont écrites nulle part dans le code.

Tout changer d’un seul coup expose facilement à des incidents du type « ça ressemble à l’original, mais ça diffère seulement en fin de mois ».

9.4 Reporter à plus tard le 32 bits / 64 bits et les références externes

Dans les projets de migration, ce n’est souvent pas le code VBA lui-même, mais

• Declare
• les DLL externes
• COM / ActiveX / OCX
• la bitness d’Office
• les références

qui explosent en premier. Reporter ces points à plus tard rend la dernière ligne droite de l’implémentation soudainement très pénible.⁷

9.5 Confondre le sujet VBScript avec le sujet VBA

Du point de vue de VBA, l’abandon progressif de VBScript est une question de révision d’une partie des dépendances. Cela ne signifie pas la fin de VBA dans son ensemble.¹⁰

Mélanger les deux sujets favorise la propagation d’une rumeur interne approximative du type « il paraît que VBA prend fin ».

10. Résumé

En un mot, VBA est un langage d’extension étroitement lié aux applications Office de bureau. Pour automatiser, tout près d’Excel et d’Access, le travail au poste de l’utilisateur, il reste aujourd’hui encore très pratique.¹

Cependant, ce qui compte pour la pratique à venir, c’est de ne pas traiter VBA comme une technologie centrale universelle.

• Pour le navigateur / le multiplateforme, regarder du côté d’Office Scripts et d’Office Add-ins⁴⁵
• Pour l’exécution sans surveillance / le traitement côté serveur, éviter l’automatisation Office⁶
• Faire sortir la logique lourde et les intégrations externes vers .NET ou un processus séparé
• Si Excel / Access devient pénible en tant qu’interface, migrer vers une application Windows ou Web

La réponse n’est ni « tout remplacer », ni « ne rien changer », mais « diviser par responsabilité et alléger progressivement ».

Vu rapidement, les actifs VBA paraissent anciens. Mais en pratique, ils contiennent une grande quantité de spécifications métier, de procédures d’exploitation, de conception de rapports et d’habitudes prises sur le terrain.

C’est précisément pour cela que le remplacement est le plus sûr lorsqu’il est mené comme une réorganisation, et non comme une traduction.

11. Articles connexes

• Que sont COM / ActiveX / OCX ? - Différences et relations expliquées ensemble
• Comment utiliser une DLL .NET 8 typée depuis VBA - exposition COM + génération d'un TLB avec dscom
• Comment construire une sortie de rapport Excel - tableau de décision entre automatisation COM / Open XML / approche par modèle

12. 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.

VBA va-t-il devenir inutilisable dans un avenir proche ?

Au moins jusqu'en mars 2026, aucune annonce officielle claire de Microsoft n'indique que VBA lui-même sera abandonné prochainement. Ce qui se produit actuellement n'est pas une suppression brutale et totale, mais une clarification des lieux où VBA peut être utilisé et de ses conditions préalables. Concrètement, Excel pour le web ne permet ni de créer, ni d'exécuter, ni de modifier du VBA, et les macros contenues dans des fichiers provenant d'Internet sont bloquées par défaut. Il est plus naturel de considérer l'avenir de VBA comme une clarification de ses limites plutôt que comme sa disparition.

Faut-il migrer tout VBA vers Office Scripts ?

Ce n'est pas recommandé. Microsoft explique lui-même qu'à l'heure actuelle, VBA couvre un périmètre de fonctionnalités Excel plus large que ce qu'offre le client de bureau via Office Scripts, et Office Scripts ne prend pas en charge les événements de niveau Excel. Il est plus juste de voir Office Scripts non pas comme un remplaçant de VBA, mais comme un composant d'automatisation sur Microsoft 365, destiné à faire fonctionner des classeurs sur OneDrive ou SharePoint en combinaison avec Power Automate. En pratique, il est plus réaliste de choisir la destination de migration responsabilité par responsabilité.

Peut-on exécuter des macros Excel sans surveillance sur un serveur ou dans un traitement batch nocturne ?

C'est risqué. Microsoft indique explicitement qu'il ne recommande ni ne prend en charge l'automatisation côté serveur des applications Office. Office est conçu en partant du principe d'un bureau interactif et d'un profil utilisateur, et dans un environnement sans surveillance, cela peut provoquer instabilité ou blocages (deadlocks). Si le besoin est de générer des rapports en grand volume, il est recommandé de ne pas lancer l'application Excel, mais de construire directement les fichiers Excel, par exemple au format Open XML.

Comment migrer les actifs VBA existants ?

Il est plus sûr de procéder par étapes plutôt que de tout reporter dès le départ sur une seule nouvelle technologie. Commencez par dresser un inventaire des actifs — fichiers .xlsm, références, DLL externes, hypothèses 32 bits/64 bits — puis répartissez le code par responsabilité : manipulation de l'interface, logique métier, rapports, entrées/sorties. Sur cette base, gardez pour l'instant l'interface et la manipulation des feuilles dans VBA, déplacez la logique métier vers des DLL .NET ou un processus séparé, orientez la génération de rapports sans surveillance vers Open XML, et confiez les flux de travail M365 à Office Scripts, en choisissant une destination par responsabilité. Pour les rapports et les agrégations, faites fonctionner l'ancienne et la nouvelle version en parallèle, comparez les sorties, puis basculez.

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.