Comment bien structurer votre programme VBA ?

Bonjour à tous,
Dans cet article nous allons voir ensemble comment organiser et structurer votre programme VBA. La première étape consistera à ouvrir l’interface de programmation. Les différentes zones de l’interface vous seront présentées. De plus je vous monterai comment je m’organise personnellement à titre d’information. C’est une manière de faire, qui me correspond. En pratiquant, vous développerez votre propre façon de faire.

Une fois l’interface présentée, nous verrons comment organiser votre code. Le but est d’avoir un code lisible et compréhensible. Si vous vous replongez dans le projet quelques mois plus tard, il faut que cela soit facile de rependre le fil.

Bonne lecture à vous !

Activation du mode développeur

Afin d’avoir accès à l’interface de développement ainsi que le module pour programmer vos outils en VBA, vous devrez activer le mode Développeur dans Excel. Cette étape permet de faire apparaître l’onglet Développeur dans l’interface Excel. Les étapes sont décrites ci-dessous :

Ouvrir l’interface VBA

Une fois le mode « Développeur » activé, vous aurez alors accès à un nouvel onglet du même nom. Pour ouvrir l’interface VBA, vous pouvez passer par l’onglet Développeur et appuyer sur le bouton « Visual Basic ». Sinon il existe le raccourci « ALT+F11 ».

Créer des modules pour organiser votre programme

Pour créer un module, c’est la même démarche que pour créer un Userform (j’en parle dans cet article). Il suffit de faire un clic droit dans la fenêtre du projet et de faire « insertion » puis « Module » comme illustré sur l’image suivant :

Une fois le module créé, il apparait automatiquement dans la liste des modules. Par défaut, ils seront renommés Module1, Module2, … Vous pouvez les renommer via la fenêtre propriétés du module. N’oubliez de sélectionner le bon module :). Pour modifier le nom du module, il suffit simplement de modifier la valeur du nom (Name) dans la fenêtre de propriétés du module.

Si la fenêtre de propriétés n’est pas visible, vous pouvez l’afficher via le menu « Affichage » puis « Fenêtre Propriétés » ou le raccourci « F4 ».

La structure de votre programme

En VBA, votre programme se décomposera en trois parties. Le programme principal qui pilotera l’outil en récupérant les données d’entrées. Ensuite, vous avez les fonctions. En VBA, une fonction est un bloc de code qui renvoie quelque chose à la fin. Enfin, on trouve aussi les procédures qui sont un petit script qui exécutera des actions sans renvoyer de valeur. Voici l’architecture des modules que j’utilise dans mes projets :

Le bloc principal

Le bloc principal est la portion de code où vous définissez tout ce dont vous avez besoin pour le bon déroulement de votre programme. Une des premières étapes est de récupérer les données d’entrée fournies par l’utilisateur. Il peut soit donner ces informations dans un fichier Excel soit via l’utilisation d’un Userform.

Sub programme_principal()

  ' Ecrivez votre programme principal ici
  ' Récupération des données d'entrée
  ' Mise en forme des données d'entrée
  ' Exécution de votre programme

End Sub

Les fonctions

Une fonction est un petit bout de code qui permet de réaliser une tâche spécifique. Cela peut être un simple calcul ou la modification d’une chaîne de caractères par exemple. Surtout, il faut garder en tête qu’une fonction ne doit qu’une seule et unique tâche. Si votre fonction commence à réaliser plusieurs tâches, c’est que celle-ci peut être scindée en plusieurs fonctions.

Il faut utiliser des noms de fonctions explicites. Ainsi, lorsque vous les appellerez dans votre code, l’utilisateur (ou vous-même) comprendra directement ce que vous cherchez à faire.

La fonction prend des arguments en entrée. Dans notre exemple, ce sont les variables a et b qui sont définies comme des nombres entiers. Le fait de déclarer le type des arguments permet de faire remonter des erreurs qui permettent de mieux analyser le code si besoin.

Enfin, pour renvoyer le résultat de la fonction, il faut utiliser le nom de celle-ci suivi du signe « = ».

Function addition(a As Integer, b As Integer)

    ma_fonction_simple = a + b
    
End Function

Les procédures

Les procédures, contrairement aux fonctions, ne renvoient pas de valeur. Elles permettent d’exécuter différentes actions sans pour autant renvoyer une valeur en retour que vous utiliserez dans votre code. Par exemple, j’ai souvent besoin de créer une procédure qui va écrire les résultats dans une feuille Excel. Ma procédure a donc besoin des données à écrire comme argument puis elle va automatiquement remplir un tableau Excel. Aucune information n’est renvoyée vers le programme principal dans ce cas. Voici un exemple de procédure simple :

Sub afficher(message As String)

    MsgBox message
    
End Sub

Cette procédure est très simple bien sûr. Vous pourrez développer les vôtres pour réaliser plus d’actions. Les procédures sont déclarées avec le mot clé « Sub » et terminées par « End Sub ». Vous renseignerez alors le nom de la procédure et les éventuels arguments dont elle a besoin.

Modules annexes

En plus des modules cités précédemment (principal, fonctions et procédures), vous pouvez avoir besoin d’utiliser des modules annexes dans lesquels vous réaliserez des actions différentes. A titre d’exemple, je crée également un module de tests dans lequel je stocke tous mes essais afin de vérifier le comportement d’une procédure ou d’une fonction. Egalement, je crée parfois un module dédiée à la vérification des données d’entrées. Ce module comporte alors tout le programme qui permet de vérifier les données d’entrée du programme.

Module de tests

Ce module est un peu fourre tout. Il me permet de tester des morceaux de code où je veux être certain du comportement. On retrouvera alors des procédures ou des fonctions. Il est important de garder ces codes car ils peuvent vous resservir un jour. Par exemple, si vous reprenez votre code 6 mois plus tard et que vous vous posez la question sur le comportement d’un bloc de code. Si vous avez encore votre test, vous saurez tout de suite s’il fonctionne ou non.

Modules de vérification

Je ne vais pas tourner autour du pot, cette partie n’est pas des plus rigolotes. Lorsque je crée un module de vérification, celui-ci va analyser les données d’entrées fournies par l’utilisateur. Le but de cette procédure est de pouvoir renvoyer un message d’erreur clair et précis. Si votre outil est dédié à d’autres utilisateurs (ce qui est souvent le cas), je vous conseille fortement de réaliser ce genre de procédure. L’élaboration de celle-ci vous prendra quelques heures mais vous en gagnerez énormément en service « après-vente » après. On n’image pas le nombre de fois où on peut être dérangé parce que l’utilisateur n’a juste pas suivi les instructions correctement. Si un message d’erreur apparaît, il pourra être guidé et cela vous évitera bien des soucis.

Une technique je me mets en pratique est de noter les erreurs potentielles que peuvent faire les utilisateurs. Comme j’ai déjà un module dédié à la vérification, je peux noter en vrac toutes les idées qui me viennent. En effet, c’est quand nous construisons notre code que nous voyons les erreurs possibles. Ainsi, au fur et à mesure, vous aurez une base de données d’erreurs à contrôler.

Si une erreur est détectée, vous pouvez alors soit mettre directement un message d’erreur pour prévenir l’utilisateur. Cependant si le nombre d’erreurs est élevé, cela peut venir devenir ennuyeux de cliquer sur le bouton pour enlever le message à chaque fois.

Une autre technique consiste à écrire dans un fichier texte le message d’erreur. En fin de procédure de vérification, vous afficherez alors un message comme quoi l’utilisateur doit se référer à ce fichier pour résoudre les problèmes. Il faudra donc faire attention à ce que le message soit explicite avec le type d’erreur, la zone qui pose problème, … toute information qui pourrait être utile à l’utilisateur. Il faut vraiment se mettre à sa place.

Ainsi, la compréhension de la cause du problème est beaucoup plus simple pour l’utilisateur. Celui-ci ne viendra plus vous déranger toutes les cinq minutes pour savoir pourquoi le programme ne marche alors que le problème vient de lui 🙂

Et maintenant à vous de jouer !

Je ne dis pas que ma façon de faire est la meilleure mais c’est déjà une proposition pour vous donner des idées. L’objectif de cet article est essentiellement de faire vous faire réfléchir sur la structure de votre programme afin de le rendre lisible, simple et compréhensible.

Si vous ne savez comment commencer, vous pouvez déjà tester ma façon de faire. Avec l’expérience, libre à vous d’appliquer la méthode qui vous convient.