Se préparer à l'abandon de VBScript : guide d'audit pour VBA, les macros Excel et les outils internes

Résumé exécutif

En avril 2026, Microsoft a publié sa politique d’abandon progressif de VBScript : dans Windows 11 version 24H2, il devient d’abord une fonctionnalité à la demande (Feature on Demand) activée par défaut ; dans la phase suivante, il devient désactivé par défaut ; et dans la phase finale, sa suppression est prévue lors d’une future version de Windows. Autrement dit, ce qu’il faut vraiment faire dès maintenant, avant toute « réécriture complète », c’est « rendre visibles les endroits où l’on dépend de VBScript ».

Pour VBA et les macros Excel, les enjeux concrets se résument à deux points. Le premier concerne les cas où l’on exécute .vbs en externe ; le second concerne les références à des bibliothèques de type VBScript telles que VBScript.RegExp. Pour ce second point, à partir d’Office version 2508 (Build 19127.20154), la classe RegExp est intégrée en standard dans le VBE, ce qui facilite désormais la migration d’au moins une partie des dépendances à RegExp. En revanche, dans les environnements mixtes où subsistent d’anciens clients Office, un même code VBA a tendance à fonctionner sur certains postes et pas sur d’autres.

Ce qui complique la migration, ce n’est pas tant VBScript lui-même que « ce qui l’entoure sur le plan opérationnel ». Par exemple, même en remplaçant l’appel par le lancement de powershell.exe depuis Excel, cela ne fonctionnera pas en production si l’on se heurte aux règles de réduction de la surface d’attaque « Bloquer la création de processus enfants par les applications Office » ou « Bloquer les appels d’API Win32 depuis les macros Office », à AppLocker, à App Control for Business, à la politique d’exécution PowerShell, aux pratiques de signature, ou au contrôle des macros sur les fichiers porteurs du marqueur MOTW. Le plan de migration doit donc être conçu en incluant non seulement la conversion du code, mais aussi la politique, la signature et l’audit des journaux.

Le chemin le plus court est le suivant : inventaire → détection statique → collecte des journaux d’exécution → choix du remplacement → tests → déploiement progressif. Cet article suit cet ordre pour un usage pratique.

Le code présenté dans cet article est par ailleurs publié sur GitHub sous forme d’un ensemble d’exemples exécutables et testables (scripts d’audit PowerShell, exemples de remplacement, code de référence VBA et Office Scripts, tests Pester).

vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide - komurasoft-blog-samples (GitHub)

Clarifier ce qui change

Le premier point à retenir est que le sujet n’est pas « VBA est abandonné ». Ce que Microsoft a publié concerne strictement l’abandon progressif de VBScript, et l’impact sur les projets VBA se concentre principalement sur l’exécution de .vbs externes et les références à des bibliothèques de la famille VBScript. Le Microsoft 365 Developer Blog identifie d’ailleurs l’exécution de .vbs depuis VBA et l’utilisation de VBScript.RegExp comme les points d’impact représentatifs.

Pour les priorités concrètes, ce tableau facilite la décision.

Cette hiérarchisation est un jugement pratique fondé sur le calendrier d’abandon de VBScript côté Windows, la stratégie de détection officielle, et les spécifications d’ASR, d’AppLocker et d’App Control.

RegExp fait toutefois un peu figure d’exception. À partir d’Office version 2508, la classe RegExp est incluse en standard côté VBE, ce qui fait que pour les seuls usages de RegExp, « une partie de la dépendance à VBScript peut désormais être résolue par une mise à jour d’Office ». Cela dit, cela ne se résout pas automatiquement dans les organisations qui conservent d’anciennes versions d’Office, des canaux de mise à jour lents, des environnements mixtes ou d’anciennes images de poste. Il est important de consigner à la fois « la mise à jour d’Office » et « le basculement progressif de Windows » dans un même inventaire.

Comment mener l’inventaire

Un inventaire fondé uniquement sur la recherche par nom de fichier ne suffit pas. Nous recommandons de conserver, au minimum, les dix aspects suivants comme colonnes, par dossier, par outil et par processus métier.

• (1) Méthode de détection des points de dépendance à VBScript Consignez séparément la recherche de fichiers, l’analyse de code et l’analyse des journaux.
• (2) Utilisation de CreateObject / GetObject / Execute / ExecuteGlobal, etc. dans VBA La cible de la dépendance se cache dans une chaîne de caractères, ce qui favorise les oublis lors d’une recherche statique.
• (3) Appels de scripts externes depuis les macros Excel Suivez séparément WScript.Shell, la fonction Shell, wscript.exe / cscript.exe, et .vbs / .js / .ps1.
• (4) Dépendances aux scripts des traitements batch et outils internes Incluez les tâches planifiées, les GPO, Intune, les scripts d’exploitation sur dossiers partagés et les programmes d’installation.
• (5) Sécurité, droits, signature, politique AppLocker, App Control for Business, ASR, politique d’exécution PowerShell, signature numérique, nécessité ou non de droits administrateur.
• (6) Comparaison des technologies de remplacement et du coût de migration Comparez VBA natif, PowerShell, .NET/VSTO, Office Scripts et Power Automate.
• (7) Plan de test Distinguez les tests unitaires, d’intégration, de recette utilisateur et les nouveaux tests après application des politiques.
• (8) Procédures d’exploitation et retour arrière Précisez ce qu’il faut restaurer pour rétablir le service, et jusqu’où automatiser.
• (9) Compatibilité et performance Différences de version Office, 32/64 bits, performance des postes, charge de la collecte de journaux, délais d’expiration des flux cloud.
• (10) Étude de cas d’exemple de migration Préparez un exemple représentatif utilisable pour l’expliquer sur le terrain.

Parmi ces dix points, les GPO, les tâches planifiées, les scripts déployés par Intune, les Custom Actions MSI et la détection via Sysmon/AppLocker/App Control sont explicitement désignés comme des domaines prioritaires dans les indications officielles de Microsoft.

Le déroulé global de la migration reste cohérent si on le représente comme dans ce schéma.

flowchart TD
    A[Inventaire des actifs] --> B{Type de dépendance}
    B -->|Exécution externe de .vbs| C[Remplacer par PowerShell ou VBA natif]
    B -->|VBScript.RegExp| D[Regrouper vers le RegExp intégré d'Office 2508+]
    B -->|GPO / Tâches / MSI| E[Corriger les paramètres à gestion centralisée et les éléments distribués]
    B -->|Dépendance inconnue / enfouie| F[Collecter les journaux d'exécution via Sysmon / AppLocker / App Control]
    C --> G[Test unitaire]
    D --> G
    E --> H[Test d'intégration]
    F --> H
    H --> I[Déploiement pilote en mode audit]
    I --> J[Désactivation progressive du FOD VBScript]

En respectant cet ordre, on évite largement le scénario classique où l’on réécrit d’abord le code, pour se le voir bloquer ensuite par une GPO ou par ASR — et devoir tout recommencer.

Détection pratique et exemples de code

Recherche de fichiers et recensement de la configuration

Les indications de détection de Microsoft recommandent de rechercher récursivement .vbs en priorisant les chemins à usage clairement défini — C:\Users, C:\ProgramData, C:\Scripts, etc. — et de vérifier séparément les GPO, les tâches planifiées, les scripts déployés par Intune et les packages MSI. La surveillance de vbscript.dll par Sysmon est efficace, mais la surveillance Image Load engendre un volume de journaux et une charge d’exploitation importants ; il convient donc de la valider d’abord sur un petit pilote.

# Balayage approximatif des dépendances aux scripts sur les postes et les dossiers partagés
$paths = @("C:\Users", "C:\ProgramData", "C:\Scripts")
$patterns = @(
  'wscript\.exe',
  'cscript\.exe',
  '\.vbs(\s|$)',
  'VBScript\.RegExp',
  'WScript\.Shell',
  'CreateObject\("VBScript\.RegExp"\)',
  'ExecuteGlobal'
)

$hits = foreach ($path in $paths) {
  if (Test-Path $path) {
    Get-ChildItem -Path $path -Recurse -File `
      -Include *.vbs,*.ps1,*.bat,*.cmd,*.wsf,*.hta,*.txt `
      -ErrorAction SilentlyContinue |
      Select-String -Pattern $patterns -AllMatches |
      Select-Object Path, LineNumber, Line
  }
}

$hits | Export-Csv .\vbscript-dependency-hits.csv -NoTypeInformation -Encoding UTF8

Ensuite, examinons le Planificateur de tâches. Pour les outils internes, plus souvent que dans les fichiers, wscript.exe / cscript.exe / .vbs se trouve enfoui dans les définitions de tâches.

# Extraire les appels VBScript des tâches planifiées
Get-ScheduledTask | ForEach-Object {
  foreach ($a in $_.Actions) {
    if ($a.Execute -match 'wscript|cscript|mshta' -or $a.Arguments -match '\.vbs\b') {
      [pscustomobject]@{
        TaskName  = $_.TaskName
        TaskPath  = $_.TaskPath
        Execute   = $a.Execute
        Arguments = $a.Arguments
      }
    }
  }
} | Export-Csv .\task-vbscript-dependencies.csv -NoTypeInformation -Encoding UTF8

Analyse du code VBA

Côté VBA, se contenter de regarder la boîte de dialogue des références ne suffit pas. CreateObject et GetObject peuvent instancier un objet COM à partir d’une chaîne de caractères, si bien qu’une dépendance peut exister même si rien n’apparaît dans les références. La documentation VBA/Office de Microsoft décrit d’ailleurs CreateObject comme le moyen de base pour créer un objet COM, et FileSystemObject ou Scripting.Dictionary sont utilisés sous cette forme également. Par ailleurs, pour lire un projet VBA par programmation, il faut activer « Approuver l’accès au modèle d’objet du projet VBA ».

' Prérequis :
'  - Activer « Approuver l'accès au modèle d'objet du projet VBA » dans le Centre de gestion de la confidentialité
'  - Les projets protégés nécessitent un export du code source séparé ou une confirmation auprès du responsable
Sub ScanProjectForVbScriptRisks()

    Dim comp As Object
    Dim cm As Object
    Dim ws As Worksheet
    Dim nextRow As Long
    Dim patterns As Variant
    Dim p As Variant
    Dim i As Long
    Dim lineText As String

    patterns = Array( _
        "CreateObject(""VBScript.RegExp"")", _
        "VBScript.RegExp", _
        "WScript.Shell", _
        "Shell(", _
        ".vbs", _
        "wscript.exe", _
        "cscript.exe", _
        "ExecuteGlobal", _
        "Execute(" _
    )

    Set ws = ThisWorkbook.Worksheets.Add
    ws.Range("A1:D1").Value = Array("Module", "Line", "Pattern", "Code")
    nextRow = 2

    For Each comp In ThisWorkbook.VBProject.VBComponents
        Set cm = comp.CodeModule

        For i = 1 To cm.CountOfLines
            lineText = cm.Lines(i, 1)
            For Each p In patterns
                If InStr(1, lineText, CStr(p), vbTextCompare) > 0 Then
                    ws.Cells(nextRow, 1).Value = comp.Name
                    ws.Cells(nextRow, 2).Value = i
                    ws.Cells(nextRow, 3).Value = p
                    ws.Cells(nextRow, 4).Value = lineText
                    nextRow = nextRow + 1
                End If
            Next p
        Next i
    Next comp

    ws.Columns.AutoFit
    MsgBox "Scan finished: " & (nextRow - 2) & " hits"

End Sub

Ce balayage capture au minimum CreateObject("VBScript.RegExp"), WScript.Shell, Shell(, .vbs et ExecuteGlobal. L’exécution de chaînes comme Execute / ExecuteGlobal en particulier est un terrain propice aux oublis d’inventaire, car la cible de la dépendance et le code exécuté sont assemblés dynamiquement.

Analyse des journaux

Au stade de l’examen des journaux d’exécution, la combinaison Sysmon + AppLocker/App Control est particulièrement efficace. Sysmon permet de suivre les chargements de vbscript.dll via l’Event ID 7, et les événements d’autorisation/audit d’AppLocker pour les scripts et les MSI peuvent être consultés dans l’Observateur d’événements. En exécutant App Control for Business en mode audit, les scripts et les MSI sont consignés dans le journal AppLocker\MSI and Script.

# Sysmon : rechercher les processus ayant chargé vbscript.dll
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 2000 |
  Where-Object { $_.Id -eq 7 -and $_.Message -match 'vbscript\.dll' } |
  Select-Object TimeCreated, MachineName, Message

# AppLocker / App Control : vérifier les journaux d'audit relatifs aux scripts et aux MSI
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/MSI and Script" -MaxEvents 2000 |
  Where-Object { $_.Id -in 8005, 8006 } |
  Select-Object TimeCreated, Id, Message

Ce qui compte ici, c’est de collecter non seulement les journaux « ça fonctionne », mais aussi ceux qui indiquent « en mode audit, cela aurait dû être bloqué ». Les événements d’audit d’AppLocker et le mode audit d’App Control sont particulièrement adaptés à une vérification de sécurité avant tout blocage en production.

Exemples minimaux de remplacement

Pour un traitement du niveau d’un appel à un .vbs externe pour écrire un CSV, le chemin le plus court consiste à d’abord le remplacer par du VBA natif.

Sub ExportCsvNativeVba()

    Dim f As Integer
    Dim outPath As String

    outPath = ThisWorkbook.Path & "\out.csv"
    f = FreeFile

    Open outPath For Output As #f
    Print #f, "Code,Name"
    Print #f, "1001,Tokyo"
    Print #f, "1002,Osaka"
    Close #f

    MsgBox "CSV exported: " & outPath

End Sub

S’il faut appeler un traitement externe depuis Excel — englobant l’OS, les dossiers partagés, l’AD, les programmes d’installation et la collecte de journaux —, il est plus réaliste de se tourner vers PowerShell. Microsoft recommande PowerShell comme remplacement de VBScript, et PowerShell dispose de moyens officiels pour la politique d’exécution, la signature et la vérification Authenticode. Notez que Shell en VBA est asynchrone par défaut : pour les traitements nécessitant un contrôle de l’ordre d’exécution, il faut prévoir une conception de flux ou une gestion d’attente séparée.

Sub RunModernPs()

    Dim cmd As String
    cmd = "powershell.exe -NoProfile -File """ & ThisWorkbook.Path & "\Normalize.ps1""" & _
          " -InputFile """ & ThisWorkbook.Path & "\in.csv""" & _
          " -OutputFile """ & ThisWorkbook.Path & "\out.csv"""

    Shell cmd, vbNormalFocus

End Sub

param(
  [string]$InputFile,
  [string]$OutputFile
)

Import-Csv $InputFile |
  Sort-Object Code |
  Export-Csv $OutputFile -NoTypeInformation -Encoding UTF8

# Appliquer et vérifier une signature
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\Normalize.ps1 -Certificate $cert
Get-AuthenticodeSignature -FilePath .\Normalize.ps1

Si le traitement Excel se termine entièrement à l’intérieur du classeur — mise en forme, agrégation, transformation, Office Scripts constitue également une option solide. Office Scripts cible Excel et convient bien à un usage basé sur le cloud, multiplateforme, et à l’intégration avec Power Automate.

function main(workbook: ExcelScript.Workbook) {
  const sheet = workbook.getActiveWorksheet();
  const used = sheet.getUsedRange();
  used.getFormat().autofitColumns();

  const tables = workbook.getTables();
  if (tables.length > 0) {
    tables[0].getSort().apply([{ key: 0, ascending: true }], true);
  }
}

Choisir la technologie de remplacement

Le choix du remplacement ne doit pas se faire selon « avec quoi peut-on l’écrire », mais selon la responsabilité qu’on souhaite lui confier. PowerShell penche vers Windows, les fichiers, les tâches et les programmes d’installation ; le VBA natif penche vers l’intérieur d’Office ; Office Scripts penche vers le traitement des classeurs Excel ; VSTO/.NET penche vers une intégration bureautique lourde ; et Power Automate penche vers l’orchestration. Le tableau ci-dessous est une estimation pratique fondée sur les caractéristiques officiellement publiées de chaque approche. Les charges de travail sont des repères donnés par l’auteur.

Pour représenter ce guide de sélection de façon plus intuitive, voici le schéma.

flowchart TD
    A[Dépendance VBScript détectée] --> B{Se termine à l'intérieur du classeur Excel ?}
    B -->|Oui| C[VBA natif]
    B -->|Oui, avec priorité au partage/cloud| D[Office Scripts]
    B -->|Non| E{Touche l'OS, les fichiers, les tâches, l'AD ?}
    E -->|Oui| F[PowerShell]
    E -->|Non| G{Intégration UI lourde ou complément à longue durée de vie ?}
    G -->|Oui| H[.NET / VSTO]
    G -->|Déclenché par un flux ou centré sur l'approbation| I[Power Automate]

Une précision sur RegExp seulement : dans un environnement où seules des versions Office 2508 ou ultérieures sont présentes, se regrouper vers Dim re As RegExp / Set re = New RegExp est assez efficace. Mais si ne serait-ce qu’un seul poste avec un ancien Office subsiste, ce code se heurte au mur de la compatibilité de compilation. Dans les environnements mixtes, il faut d’abord décider si la politique de migration sera « nouvelle syntaxe », « ancienne syntaxe » ou « wrapper de branchement ».

Tests et exploitation

Plan de test

Une migration VBScript ne se limite pas aux tests unitaires. Sans un nouveau test dans des conditions équivalentes à la production, avec les politiques de sécurité actives, le script PowerShell ou .NET de remplacement s’arrêtera pour une tout autre raison. La documentation de Microsoft traite d’ailleurs la politique d’exécution PowerShell, AppLocker, le mode audit d’App Control, ASR et le contrôle des macros sur fichiers MOTW comme des règles distinctes.

Voici les points les plus fréquemment négligés.

• Un remplacement où Excel lance PowerShell peut se heurter à la règle ASR « Bloquer la création de processus enfants par les applications Office ».
• Conserver des déclarations VBA ou des appels d’API peut se heurter à la règle ASR « Bloquer les appels d’API Win32 depuis les macros Office ».
• Un .xlsm / .ps1 de test distribué via un téléchargement ou une pièce jointe change de comportement selon le marqueur MOTW et l’état de la signature.
• La combinaison Office Scripts et Power Automate est pratique, mais pour de gros CSV ou un grand nombre de cellules, il faut tenir compte des délais d’expiration et des limites de transfert de données.
• La surveillance Image Load de Sysmon est utile, mais si on l’étend sans discernement à toute l’entreprise, le volume de journaux augmente rapidement.

Liste de contrôle de la procédure de migration

• Recherche statique effectuée pour .vbs, wscript.exe, cscript.exe, VBScript.RegExp, WScript.Shell, Shell(, ExecuteGlobal
• Inventaire réalisé séparément pour les GPO, les tâches planifiées, Intune, l’exploitation des dossiers partagés et les MSI
• Versions Office et canaux de mise à jour consignés dans un inventaire, avec identification des postes restant sous la version 2508
• Remplacement choisi parmi « VBA natif / PowerShell / .NET / Office Scripts / Power Automate »
• Politique de signature et politique de distribution des certificats définies
• Impact d’AppLocker / App Control / ASR / de la politique d’exécution testé
• Journaux d’audit collectés dans un service pilote
• Procédure de retour arrière documentée
• Preuve de « non-utilisation » conservée avant de désactiver le FOD VBScript

Risques et contre-mesures

Les contre-mesures de ce tableau transposent dans l’exploitation interne les contraintes de conception documentées dans les ressources officielles de Microsoft.

Un retour arrière ne se limite pas à « restaurer le code ». Pensez au minimum ensemble à la restauration de l’ancienne version des éléments distribués, l’annulation des politiques, la marge de manœuvre pour réactiver la fonctionnalité optionnelle, et la poursuite de la collecte des journaux. Tant que VBScript existe encore en tant que FOD, il reste possible de le réactiver en tant que fonctionnalité optionnelle conformément aux indications de la Phase 2 — mais une fois supprimé en Phase 3, cette possibilité de repli disparaît.

Étude de cas : un exemple de migration

Prenons un exemple typique : la macro d’agrégation mensuelle du service comptabilité. Dans sa forme actuelle, la macro Excel lance cleanup.vbs via WScript.Shell, valide des codes avec VBScript.RegExp après la mise en forme du CSV, puis écrit finalement le résultat dans un dossier partagé. Cette configuration subit de plein fouet l’abandon de VBScript, et même un simple portage vers PowerShell risque à nouveau de se bloquer sur ASR ou la gestion de la signature.

Dans ce cas, la bonne approche consiste à découper le problème. La validation, la mise en forme et l’agrégation qui se terminent à l’intérieur d’Excel passent en VBA natif ou vers le RegExp intégré d’Office 2508+. La conversion de fichiers et les entrées/sorties vers le dossier partagé passent à PowerShell. Si le déclencheur est « l’arrivée d’un fichier » ou « une heure fixe quotidienne », cela passe à Power Automate. Cela permet de démêler les responsabilités qui avaient été entassées dans un seul .vbs.

Voici un exemple de structure après migration.

• Macro Excel : vérification des saisies, interactions à l’écran, messages destinés à l’utilisateur
• PowerShell : normalisation du CSV, E/S vers le dossier partagé, sortie des journaux
• Gestion de la signature : signature Authenticode des scripts PowerShell
• Sécurité : vérification préalable d’AppLocker/App Control en mode audit, décision sur la nécessité d’exceptions ASR
• Extension future : migration progressive des traitements récurrents internes à Excel vers Office Scripts

L’avantage de cette approche est de se détacher rapidement de la dépendance au runtime VBScript, sans avoir à tout reconstruire d’un coup. En absorbant RegExp via la mise à jour d’Office, en déplaçant les scripts d’exploitation vers PowerShell et le flux métier vers Power Automate — en répartissant ainsi par responsabilité —, le périmètre d’impact d’une panne se réduit également.

Outils recommandés et liens de référence

• L’ensemble du code d’exemple de cet article (scripts d’audit PowerShell et tests Pester) https://github.com/gomurin0428/komurasoft-blog-samples/tree/main/vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide

Nous recommandons de lire les ressources officielles dans cet ordre.

• VBScript deprecation: Timelines and next steps Le point de départ pour comprendre la feuille de route globale et la signification de chaque Phase.
• VBScript deprecation: Detection strategies for Windows Des indications de détection pratiques couvrant Sysmon, les GPO, les tâches planifiées, Intune et les Custom Actions MSI.
• Prepare your VBA projects for VBScript deprecation in Windows Le document le plus important du point de vue VBA. Il regroupe l’intégration de RegExp, le traitement d’Office 2508 et versions ultérieures, ainsi qu’un tableau de compatibilité.
• Différences entre les scripts Office et les macros VBA Une ressource utile pour décider si les traitements centrés sur Excel doivent être déplacés vers Office Scripts.
• about_Execution_Policies / about_Signing / Set-AuthenticodeSignature / Get-AuthenticodeSignature L’ensemble de base pour la gestion de la signature et de la politique d’exécution lors d’une migration vers PowerShell.
• Using Event Viewer with AppLocker / Use audit events to create App Control policy rules / Application des scripts avec App Control for Business Nécessaire pour comprendre la conception du mode audit, la collecte d’événements et le comportement d’application des scripts.
• Référence des règles de réduction de la surface d’attaque Une ressource pour vérifier les règles de blocage relatives aux processus enfants Office, aux API Win32 et à l’exécution de téléchargements JS/VBS.
• Les macros provenant d’Internet sont bloquées par défaut dans Office Une lecture indispensable pour comprendre les problèmes liés au marqueur MOTW lors des distributions de test et des déploiements en production.

Comme outils complémentaires, voici ceux que nous utilisons souvent dans la pratique.

• Sysmon La base pour surveiller les chargements de vbscript.dll et collecter les événements liés aux processus.
• Modèles de configuration Sysmon sur GitHub Le sysmon-config de SwiftOnSecurity est un modèle initial de grande qualité, et le sysmon-modular d’Olaf Hartong est un point de départ modulaire et facile à exploiter.
• oletools / olevba Bien adapté pour extraire le code source VBA des fichiers Office et aider à détecter des mots-clés suspects ou des macros à exécution automatique.

En conclusion, se préparer à l’abandon de VBScript ne se limite pas à « chercher VBScript et le remplacer par PowerShell ». Gérer dans un même inventaire les mises à jour d’Office, l’analyse de code, la configuration opérationnelle, la signature, ASR/AppLocker/App Control et les UAT est la démarche la plus rapide et la plus fiable. Sauvez rapidement ce qui peut l’être par une mise à jour d’Office, comme RegExp, et détachez en priorité ce qui risque de casser lors des basculements progressifs côté Windows, comme l’exécution de .vbs et les dépendances aux GPO/tâches/MSI.

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 est-il également concerné par l'abandon de VBScript ?

Non : la politique publiée par Microsoft porte exclusivement sur l'abandon progressif de VBScript, pas sur VBA. L'impact sur les projets VBA se concentre sur deux points : l'exécution de fichiers .vbs externes depuis VBA ou des macros Excel, et les références à des bibliothèques de la famille VBScript telles que VBScript.RegExp. Pour RegExp en particulier, à partir de la version Office 2508, la classe RegExp est intégrée en standard dans le VBE, ce qui permet de résoudre une partie de cette dépendance par une simple mise à jour d'Office. En revanche, dans les environnements mixtes où subsistent d'anciens clients Office, le même code VBA peut fonctionner sur certains postes et échouer sur d'autres.

Quel est le calendrier de suppression de VBScript sous Windows ?

Microsoft abandonne VBScript en plusieurs phases : dans Windows 11 version 24H2, il devient d'abord une fonctionnalité à la demande (Feature on Demand) activée par défaut ; dans la phase suivante, il devient désactivé par défaut ; et dans la phase finale, sa suppression est prévue lors d'une future version de Windows. Tant que VBScript existe encore en tant que fonctionnalité à la demande, il reste possible de le réactiver conformément aux indications de la Phase 2, mais une fois supprimé en Phase 3, cette possibilité de repli disparaît. La priorité pratique aujourd'hui est de rendre visibles les dépendances à VBScript, plutôt que de se précipiter vers une réécriture complète.

Comment trouver toutes les dépendances à VBScript dans mon organisation ?

Combinez recherche statique et journalisation d'exécution, car une simple recherche par nom de fichier laisse échapper les dépendances cachées dans des chaînes de caractères. Recherchez statiquement des motifs comme .vbs, wscript.exe, cscript.exe, VBScript.RegExp, WScript.Shell et ExecuteGlobal dans les chemins utilisateurs, et inventoriez séparément les scripts de connexion GPO, les tâches planifiées, les scripts déployés par Intune et les Custom Actions VBScript des MSI. Côté VBA, analysez les modules de code par programmation, car CreateObject peut instancier un objet COM à partir d'une chaîne sans que rien n'apparaisse dans la boîte de dialogue des références. Pour les dépendances enfouies, collectez les journaux d'exécution via Sysmon (chargements de vbscript.dll, Event ID 7) ainsi qu'AppLocker ou App Control for Business en mode audit.

Par quoi remplacer VBScript ?

Choisissez en fonction de la responsabilité à assumer, plutôt qu'en fonction du langage. Les traitements qui se terminent entièrement à l'intérieur d'un classeur Excel passent en VBA natif ou vers le RegExp intégré à partir d'Office 2508 ; les opérations sur fichiers, dossiers partagés, AD, tâches et programmes d'installation passent à PowerShell, le remplacement recommandé par Microsoft ; les traitements centrés sur Excel exécutés dans le cloud conviennent à Office Scripts ; et les déclencheurs tels que l'arrivée d'un fichier ou une planification conviennent à Power Automate. Gardez à l'esprit que la migration est plus difficile que la simple conversion du code : un remplacement où Excel lance powershell.exe peut être bloqué par les règles de réduction de la surface d'attaque, AppLocker, App Control, la politique d'exécution ou l'absence de signature — il faut donc retester dans des conditions de sécurité équivalentes à la production avant le déploiement.

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.