Blog / Article #130

VBA en 2026 : le langage qui refuse de s’éteindre

Le code VBA est un langage de programmation intégré aux logiciels de la suite Microsoft Office permettant d'automatiser des tâches répétitives. En 2026, VBA (Visual Basic for Applications) est toujours là, tapi dans l’ombre des macros Excel, comme un vieux chat qui refuse de quitter le canapé. On pourrait croire qu’il a été remplacé par des trucs plus modernes – Python, PowerShell, ou même les fonctions natives d’Office 365. Pourtant, non. VBA persiste, et pas seulement dans les entreprises où le temps s’est arrêté en 2005. Alors, pourquoi ? Et surtout, pourquoi est-ce à la fois génial et désespérant ?

VBA en 2026 : où et pourquoi ?

D’abord, soyons clairs : VBA n’est plus le roi du développement. Mais il reste le roi de l’automatisation rapide et sale dans les environnements Microsoft. Voici où on le trouve encore :

• Excel, toujours Excel : Les tableaux croisés dynamiques, c’est bien. Les macros qui font le boulot à votre place, c’est mieux. VBA permet de scripter des tâches répétitives en quelques lignes, sans avoir à sortir de l’écosystème Office. Et comme Excel reste l’outil préféré des comptables, des RH et des managers qui aiment les graphiques en camembert, VBA a encore de beaux jours devant lui.
• Les legacy systems : Certaines entreprises traînent des applications internes codées en VBA depuis les années 90. Les migrer coûterait plus cher que de garder un stagiaire pour maintenir le code. Résultat : VBA survit, comme une moisissure tenace.
• L’automatisation low-code : Pour les non-développeurs, VBA est souvent le premier langage qu’ils apprennent. Pas besoin de comprendre les promesses ou les décorateurs Python – un Sub et un End Sub, et hop, ça marche (ou pas). C’est l’équivalent informatique du bricolage avec du scotch et des trombones.

Pourquoi est-ce que ça marche encore ? Parce que VBA est intégré. Pas besoin d’installer quoi que ce soit, pas de dépendances à gérer, pas de conflits de versions. Ouvrez Excel, appuyez sur Alt + F11, et vous êtes dans l’IDE. C’est aussi simple que de brancher une clé USB (enfin, presque).

Pourquoi VBA est moche (et c’est assumé)

Parlons peu, parlons code. Voici un exemple de script VBA qui fait quelque chose d’utile : extraire des données d’un tableau Excel et les envoyer dans un email. C’est laid, c’est verbeux, et c’est exactement pour ça qu’on l’aime (ou pas).

Sub EnvoyerDonneesParEmail()
    Dim OutApp As Object
    Dim OutMail As Object
    Dim ws As Worksheet
    Dim derniereLigne As Long
    Dim corpsEmail As String
    
    Set ws = ThisWorkbook.Sheets("Données")
    derniereLigne = ws.Cells(ws.Rows.Count, "A").End(xlUp).Row
    
    ' Construction du corps de l'email (parce que HTML, c'est trop compliqué)
    corpsEmail = "Bonjour," & vbCrLf & vbCrLf
    corpsEmail = corpsEmail & "Voici les dernières données :" & vbCrLf & vbCrLf
    
    For i = 2 To derniereLigne
        corpsEmail = corpsEmail & ws.Cells(i, 1).Value & " - " & ws.Cells(i, 2).Value & vbCrLf
    Next i
    
    ' Création de l'email (parce que Outlook, c'est la vie)
    Set OutApp = CreateObject("Outlook.Application")
    Set OutMail = OutApp.CreateItem(0)
    
    With OutMail
        .To = "chef@entreprise.com"
        .Subject = "Données du jour"
        .Body = corpsEmail
        .Send ' Ou .Display si vous voulez vérifier avant envoi
    End With
    
    ' Nettoyage (parce que les objets COM, c'est comme les ex : ça traîne)
    Set OutMail = Nothing
    Set OutApp = Nothing
    
    MsgBox "Email envoyé !", vbInformation
End Sub

Ce code est horrible. Voici pourquoi :

• La syntaxe : Dim, Set, As Object… On dirait du BASIC des années 80, parce que c’en est. Pas de typage fort, pas de gestion moderne des erreurs, juste des On Error Resume Next qui font frémir.
• Les objets COM : Pour interagir avec Outlook, on utilise des objets COM, une technologie qui date de l’époque où Windows 95 était considéré comme innovant. Les fuites mémoire ? Les plantages aléatoires ? Bienvenue dans le monde merveilleux de VBA.
• L’IDE : L’éditeur VBA est une relique. Pas de complétion intelligente digne de ce nom, pas de refactoring automatique, pas de gestion de versions intégrée. C’est comme coder dans Notepad, mais en moins pratique.
• La documentation : La plupart des ressources en ligne datent des années 2000. Si vous cherchez de l’aide sur Stack Overflow, préparez-vous à tomber sur des réponses du type « Ça marche chez moi, essaye de redémarrer ton PC ».

Pourtant, malgré tout ça, VBA reste efficace. Pas élégant, pas scalable, mais efficace. En quelques lignes, vous pouvez automatiser des tâches qui prendraient des heures à faire manuellement. Et c’est ça, le vrai pouvoir de VBA : il permet de faire des trucs vite fait, mal fait, mais qui marchent.

Pourquoi VBA est puissant (et c’est ça, le problème)

VBA est puissant parce qu’il est partout. Microsoft a essayé de le tuer – d’abord avec VSTO (Visual Studio Tools for Office), puis avec les Office Add-ins en JavaScript, et enfin avec Power Automate. Mais rien n’y fait : VBA résiste. Pourquoi ? Parce qu’il est simple.

Voici ce que VBA fait bien :

• Automatisation rapide : Pas besoin de configurer un environnement de développement complexe. Ouvrez Excel, écrivez votre macro, et c’est parti. C’est l’équivalent informatique du fast-food : pas bon pour la santé, mais ça dépannera toujours.
• Intégration avec Office : VBA peut interagir avec Word, Excel, Outlook, Access, et même PowerPoint (si vous osez). C’est le couteau suisse de l’automatisation bureautique.
• Accessibilité : Pas besoin d’être développeur pour écrire une macro. Un comptable, un RH, ou même un manager peut bidouiller un script qui lui fait gagner du temps. C’est le low-code avant l’heure, mais en plus laid.

Le problème, c’est que cette puissance est trompeuse. VBA donne l’illusion que tout est simple, jusqu’à ce que vous vous retrouviez avec un script de 2000 lignes qui plante tous les lundis matin, et que personne ne sait comment le déboguer. Parce que oui, VBA encourage les mauvaises pratiques : pas de tests unitaires, pas de gestion des erreurs propre, pas de séparation des responsabilités. C’est le Far West du développement.

Et puis, il y a le problème de la dette technique. Les entreprises qui utilisent VBA depuis 20 ans ont accumulé des montagnes de code legacy. Migrer vers autre chose (Python, PowerShell, ou même les fonctions natives d’Excel) coûterait cher, et personne ne veut payer. Alors on garde VBA, on ajoute des patches, et on prie pour que ça tienne encore un peu.

VBA en 2026 : un mal nécessaire ?

Alors, faut-il jeter VBA aux oubliettes ? Pas forcément. Comme le COBOL ou le Fortran, VBA a sa place dans l’écosystème informatique. Il n’est pas beau, il n’est pas moderne, mais il est utile. Pour les petites automatisations, pour les scripts jetables, ou pour dépanner un collègue en panique, VBA reste un outil précieux.

Mais attention : VBA n’est pas un langage de développement sérieux. Si vous voulez écrire du code maintenable, scalable, et testable, passez votre chemin. Utilisez Python, PowerShell, ou même les nouvelles fonctions d’Office 365. VBA, c’est comme le sucre : ça fait du bien sur le moment, mais à long terme, ça pourrit les dents.

En 2026, VBA est toujours là, et il n’est pas prêt de disparaître. Parce que dans le monde du développement, parfois, le pire outil est aussi le plus pratique. Et ça, c’est à la fois rassurant et terrifiant.